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RESUME 


Nous présentons ici un système LISP : VLISP, implémenté depuis cing 
ans sur différents ordinateurs (CAB 500, CAE 510, T 1600, PDP 10) à l'Uni- 
versité Paris 8. 


Nous donnons la description complète du noyau de VLISP 4 travers 
l'étude systématique de plusieurs de ses réalisations existantes. Les 
résultats expérimentaux obtenus dans ces réalisations seront comparés à 
un certain nombre de versions classiques : LISP 1.5, MACLISP, INTERLISP 
et LISP 1.6. 


L'exposé prendra en compte les fondements théoriques de LISP et de 
ses dérivés, rassemblés sous le nom de lambda-langages. Nous examinerons, 
du point de vue de l'implémenteur, quelques uns des concepts, problèmes et 
solutions dégagés par les études théoriques en lambda-calcul : continuations, 
environnements , fermetures et funargs. 


Pour décrire la structure de VLISP, système plus spécialement orienté 
pour mini-ordinateurs, nous proposons une nouvelle méthode de spécification 
de LISP fondée sur le filtrage d'expressions symboliques : cette méthode 
est un outil d'implémentation de LISP et de tous ses dérivés. 


Nous proposerons plusieurs structures de contrôle originales en 
LISP, en particulier SELF, ESCAPE et MULTIPLE, permettant de réduire 
considérablement la taille mémoire requise à l'exécution. 


Nous décrirons comment l'interprète VLISP élimine dynamiquement 
plusieurs types de récursivités sans transformation de programmes préalable, 
par filtrage sur la structure de la pile de récursion. Nous démontrerons, au 
moyen d'un interprète abstrait la validité de l'interprétation itérative de 
ces schémas récursifs. 


Enfin, 4 propos des outils de mise au point disponibles en VLISP, nous 
suggérons un principe d'intégration des outils de mise au point et des inter- 
prêtes, fondé sur la notion de VISION. 
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CHAPITRE Ll 


INTRODUCTION 


1.1.— PROGRAMMATION INSTABLE ET THEORIE DE LA PROGRAMMATION 


Il est souvent soutenu (cf. en particulier WARD 1974, pp. 7-8) que 
l'implémenteur d'un langage (qui dans le cas d'un dérivé de LISP se confond 
volontiers avec l'architecte)se trouve confronté au dilemme que voici : choisir 
entre d'une part une sémantique élégante et compacte, jouissant des propriétés 
logiques qui la qualifient au titre de système formel, et d'autre part, 
l'adjonction au langage, au titre de sa définition, des dispositifs 
linguistiques qui en rendront l'usage le plus commode, quitte à sacrifier 
la premier terme du dilemme au pouvoir expressif que ces dispositifs offrent 


pour l'utilisation pratique. 


Ainsi, ce serait au nom de la notion encore fort mal élucidée de 
pragmatique des langages de programmation que seraient évacuées ~ ou tout 
au moins renvoyées dans un avenir indéterminé ~ les contributions des 
études sémantiques à la définition, à l'architecture, et à l'implémentation 


de langages. 


Ce point de vue nous paraît inadéquat, tant pour des raisons liées à 
l'utilisation effective de LISP, que pour des raisons moins contingentes, liées 


aux effets de bord inhérents 4 la formalisation de toute activité empirique. 


Depuis 1960, LISP est développé, mis en oeuvre et utilisé de façon 
privilégiée par la communauté des chercheurs en Intelligence Artificielle : 
LISP était originellement l'outil conçu par J. McCARTHY en vue de la 


construction de programmes dotés de «sens commun» (McCARTHY 1958). 
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Ainsi, des solutions le plus souvent d'ordre interprétatif, issues de 
travaux théoriques se révèlent ici tout à fait adéquates à ce type de program- 
mation, en apportant à ses praticiens des mises à jour régulières de l'incom- 

lét . e * t . EN i „a . 
plétude de leurs constructions, aussi bien qu'en livrant à 1 implémentation 


immédiate des objets originellement conçus comme des outils de description 


ou de démonstration. 


L'histoire récente de la formalisation des notions de machines et de 
programmes abonde en exemples où les difficultés pointées et les objets 
abstraits issus de l'activité théorique ont eut dans la pratique des retentis- 
sements aussi profonds qu'inattendus, apparentés à ce qu'on pourrait nommer 
les effets de bord de l'activité de formalisation : la simplification, voire 
l'idéalisation d'un objet originellement mal contrôlé et complexe, produit un 
nouvel objet qui, réinséré dans des travaux plus concrets, se retrouve à 


nouveau opacifié et redevient sujet à des examens théoriques. 


A titre d'illustration : c'est à de semblables tribulations qu'à été 
soumis le concept de fermeture. 
Originellement conçu pour faire échec aux difficultés de la nomination 
multiple en lambda-calcul (CHURCH 1941) : appliqué à la description du 
langage CPL (BARRON 1963) et des générateurs - boucles FOR ~- en ALGOL 60 
(LANDIN 1965), il se retrouvait reconceptualisé a l'occasion des différents 
types de descriptions formelles de SECD machines (LANDIN 1964, 1966, McGOWAN 
1970, LEAVENWORTH 1971). Parallèlement, sa version implémentée en LISP 1.5 
sous le nom de FUNARG (McCARTHY 1962c), solution pragmatique au passage 
d'arguments et de valeurs fonctionnels, disparaissait des versions plus récentes 
de LISP (QUAM 1972, MOON 1974, GREUSSAY 1975). Il resurgissait pendant ce temps 
dans les études théoriques consacrées 4 la formalisation de structures de 
contrôle au moyen des continuations (REYNOLDS 1972, STRACHEY 1973), et se 
retrouvait peu après réapproprié par les praticiens à l'occasion de la 
construction de langages fondés sur le passage de messages (HEWITT 19/3a,b, 
1974a, 1975a,b, GREIF 1975), happant au passage un probléme de controle 
d'effets de bord : celui de la modification d'objets clôturés dans une 


fermeture. Aussi bien ce probléme d'effets de bord dans les fermetures était-il 


inhérent au concept de STREAM (LANDIN 1966, STOY 1972, 1974, BURGE 1975a,b). 
Cet objet fondamental pour la description précise des systémes d'exploitation, 
dont la formalisation était ébauchée dans MILNER (1973), réactualisait peu 
aprés concrétement le concept de fermeture, en le suggérant comme une solution 


au problème de la multiprogrammation des lambda-langages (SUSSMAN 1975). 


Ainsi, ce va et vient constant entre théorie et utilisation forme un 
aspect majeur et encore mal discerné de l'évolution des savoirs et des 
pratiques mis en jeu en programmation. N'aurait-il d'ailleurs point lieu que 
la simplification et l'élagage portés par les points de vue théoriques sur les 
objets et concepts formés et manipulés par les programmeurs se retrouveraient 
indispensables 4 la communication à des non-programmeurs, et à l'exportation 
de ces concepts dans des domaines non immédiatement informatiques : nous 
pensons ici en particulier tant à la psychologie cognitive (LINDSAY 1972, 
BOBROW 1975), qu'à la linguistique dans ses aspects sémantiques et documen- 


taires (GROSS 1972, JACKENDORFF 1975, BORILLO 1977). 


1.2.— LISP : IMPLEMENTATION, INTERPRETATION, DEVELOPPEMENT ET MISE AU POINT 


La recherche en Intelligence Artificielle se définissant essentiellement 
par la programmation de modèles de conduites, il est alors très naturel de 
s'interroger sur le comportement des programmeurs de ce domaine, à travers le 


langage majeur, utilisé dans la discipline : LISP. 


Deux grands types de préoccupations ont récemment surgi , préoccupations 


apparemment distinctes, mais en réalité très fortement convergentes 


1) on souhaite implanter des programmes d'Intelligence 
Artificielle sur une grande variété de minicalculateurs 
ceci s'explique d'une part par la limitation des ressources 
disponibles dans certains laboratoires, d'autre part par la 
nécessité de donner, par embarquement de calculateurs, une 
certaine autonomie à des dispositifs manipulatoires (robots 
opérant en milieu hostile, manipulateurs en grands fonds 


océaniques). 


2) mis en place sur de grands ordinateurs, certains programmes 
d'Intelligence Artificielle, étant donné la complexité de 
leurs structures de contrôle, deviennent difficilement 
compréhensibles , quelquefois par leur créateur lui-même 

(WINOGRAD 1975), et perdent ainsi ce qui était leur | 
motivation première : être la spécification explicite d'un 
modèle de comportement, grâce à une implémentation lisible, 
compréhensible à chacun, sujette à des expérimentations 
répétables, susceptible d'extensions au fur et à mesure de 


l'extension du modèle psychologique qu'elle spécifie. 


Dans les deux cas, nous concluons qu'il est nécessaire de dépasser 
une butée due à des limitations actuelles de ressources en pouvoir expressif 
des outils d'implémentation, des outils d'interprétation, des outils de 


programmation : développement et mise au point. 


1.2.1. OUTILS _D'IMPLEMENTATION 


Ce dépassement sera obtenu par la levée des limitations des spécifications 
du langage principalement utilisé : LISP, spécialement en ce qui concerne son 
implémentation. 

Nous avons besoin de disposer d'outils directs de programmation permettant des 
implémentations très rapides, suffisamment abstraits pour que la spécification ne 
dépende pas d'une machine particulière, suffisamment expressifs et co-naturels 

au langage et aux représentations intellectuelles inhérentes à la programmation 
en LISP pour que l'implémentation jusqu'en langage-machine soit, pour un 


programmeur averti, quasi-automatique. 


1.2.2.-— OUTILS D'INTERPRETATION 


Pour disposer de LISP sur des ordinateurs limités en taille mémoire aussi 
bien qu'en richesse d'instructions, il faut obtenir une efficacité accrue des 


interprètes qui y seront construits. 


Efficacité en rapidité d'exécution : il est remarquable que le module principal de 
l'implémentation classique de LISP, le module EVAL soit susceptible de recevoir 
n'importe quelle expression, et doive, par décompositions successives et par 
l'application de nombreux tests de type, redistribuer hiérarchiquement, a la 
maniére d'une économie centralisée, la responsabilité du calcul a plusieurs 
autres modules : EVLIS, APPLY, PROGN, et aux fonctions spécialisées en 
traitement numérique et au traitement de listes. 

Cette centralisation est ici une grande source d'inefficience. Nous avons 
besoin au contraire d'une organisation non-hiérarchique, dans laquelle chaque 
module recoit directement les messages qui lui sont adressés : le nombre de 
possibilités est alors naturellement plus restreint, et les tests de type seront 


limités au strict nécessaire. 


Efficacité aussi bien, en utilisation de l'espace mémoire disponible. Les 

études théoriques, particuliérement celles menées dans le domaine des schémas 

de programme (PATERSON 1970, STRONG 1971, 1972, WALKER 1972) nous ont appris 

que certains types de procédures récursives peuvent être validement transformés 

en procédures itératives, permettant ainsi une économie considérable de la mémoire 
disponible et donnant au programmeur des outils à pouvoir expressif accru, par 
adéquation de ses définitions d'algorithmes, très souvent récursives, avec leur 


programmation effective. 


Nous avons besoin d'interprètes «éclairés » tenant compte directement de 
ces savoirs, sans qu'il soit besoin de contraindre le programmeur a des 
transformations préalables de ses programmes, lorsque cela est possible. 

Ces interprètes doivent pouvoir reconnaître à la volée les types de schémas des 
programmes qui leur sont soumis, et réorganiser aussitôt, non pas les programmes 
interprétés (manipulation symbolique parfois trés coûteuse et souvent non 
triviale), mais leur propre gestion de l'environnement : en particulier emploi 
ou non d'une pile, construction de fermetures, calcul et passage de valeurs 
multiples, non-multiplication de noms superflus par utilisation directe d'un 


opérateur point-fixe implémenté. 
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Enfin le type d'application principal du langage LISP doit nous amener 
à reconsidérer le point de vue actuel qui consiste à rejeter la mise au point 
de programmes et ses outils, au profit d'une validation préalable par preuve 
de la correction, partielle ou totale, de ses spécifications 4 différents niveaux 
d'abstraction. 
Outre que la faillibilité n'en est certes pas absente (GERHART 1976), que les 
erreurs de programmation constituent en elles-mêmes une source de données 
considérable et encore fort mal connue sur les processus intellectuels mis 
en jeu en programmation (SUSSMAN 19743017, l'usage qui est fait de LISP en 
Intelligence Artificielle ne nous permet pas de mésestimer l'importance de la 
mise au point. | 

En programmation à long terme, le plus souvent interactive, parfois quasi- 
improvisée au terminal, en tout cas profondément incrémentale, la validation 
préalable des programmes ne semble pas être une activité prioritaire. 
Nous avons plus urgemment besoin d'un ensemble cohérent d'outils de mise au 


point de programmes, ensemble totalement intégré 


1) aux interprètes qui exécutent ces programmes sous divers 


modes 


2) aux éditeurs qui en permettent l'introduction et la 


modification. 


(1) Le conseil de Donald Ervin KNUTH (Fundamental Algorithms, 1968, Addison 
Wesley, p. 189) demeure profondément actuel 


«Another good debugging practice is to keep a record of every mistake that 
is made. Even though this will probably be quite embarassing, such infor- 


mation is invaluable to anyone doing research on the debugging 
problem, and it will also help you learn how to reduce the number of 


future errors. » 


Dans les cas simples, il semble qu'en programmation interactive, les étapes 

de mise au point, d'essais, de modifications, voire de commentaires de 

fragments de programmes peuvent être anticipés, et en quelque sorte compris et 
résumés par un tel systéme. Ce dernier sera naturellement fort complexe, 

même à se limiter aux cas les plus simples. 

Il peut sembler paradoxal de lutter ainsi avec la complexité par la mise 

en jeu d'une complexité égale, sinon supérieure (WINOGRAD 1975), mais les 
fragments encore épars d'un tel outil commencent à apparaître (DONZEAU-GOUGE 

1975, WERTZ 1976, STEIGER 1976, GOOSSENS 1977). L'aisance immédiate qu'un 
programmeur en retire laisse augurer d'excellents résultats pour une programmation 


évolutive, essentiellement non-hiérarchique. 


1.3.- PROPOSITIONS 


Les trois points que nous venons d'évoquer constituent l'objet principal 


de cette étude. 


1.3.1.- FILTRE : UNE METHODE D' IMPLEMENTATION 
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Au chapitre 4, nous proposons une méthode d'implémentation de LISP 
orientée sur les mini-ordinateurs et fondée sur un langage de spécification : 
FILTRE, ainsi nommé car opérant par filtrage d'expressions symboliques. 

Ces derniéres sont précisément les représentations externes de LISP, ce qui 

en rend la mise en jeu particuliérement naturelle au programmeur. 

Cette méthode vise à permettre l'implémentation rapide de LISP dans un langage 
de trés bas niveau, sans toutefois que les caractéristiques d'une machine 
particuliére interviennent dans la spécification. 

Affectations de registres, tests, manipulations et états de piles, structures 
de données manipulées, structures de contrôle sont ainsi spécifiés dans une 


notation unifiée. 


Voici par exemple, a partir de la définition en VLISP de la fonction de 
séquencement PROGN, utilisée dans de nombreux modules de l'interprète, 


la description en FILTRE de son implémentation : 


VLISP 


CDE PROGN CL). CCOND 
CCCDR L) CEVAL CNEXTL L)) CPROGN L)) 
CT CEVAL CCAR L))))) 


FILTRE 


PROGN = 
tantque (Al Al : P) :: CC !Al !- ?-) ?P) 
rec EVAL; P :: CC!- ?A1) ?P) 
ftan 
Al :: C!A1)3 app EVAL 


Nous avons appliqué cette méthode 4 la construction de plusieurs 
systémes LISP originaux dont le noyau et les extensions sont rassemblés sous 
le nom de VLISP. | 
L'efficacité de cette méthode de spécification a été prouvée par les 
implémentations de VLISP qui ont été menées sur plusieurs mini-calculateurs 
anciens et récents, à l'Université de Paris 8-Vincennes et à l'Institut de 
l'Environnement : CAB 500, CAE 510, T 1600 (GREUSSAY 1975), mais s'est 
trouvée également validée par son implémentation sur ordinateur plus puissant: 
PDP 10 modèle KI 10, sous système TOPS 10 à 1'IRCAM et au Centre Hospitalier 
Universitaire de la Salpêtrière à Paris (CHAILLOUX 1976, 1977). 

La méthode de spécification par filtrage s'applique également aux dérivés 

de LISP. Nous l'avons utilisée ailleurs pour décrire un sous ensemble du 
langage CONNIVER (GREUSSAY 1976a). La méthode sera ici appliquée au chapitre 5 
au langage PLASMA (SMITH 1975a). 


1.3.2.1.- Elimination dynamique de récursivités 


Nous proposons au chapitre 6 une structure d'interpréte LISP susceptible 
d'éliminer la récursivité inhérente a une certaine classe, tres fréquente dans 
la pratique, de programmes : post-récursifs simples, mutuels et enveloppés. 
Cette élimination est dynamique : ces programmes sont tnterprétés itérativement 
sans avoir à subir des transformations préalables. _ 

L'interprétation est itérative lorsque l'environnement (les valeurs précédentes 
des arguments) ou/et la continuation ne sont pas préservés inutilement lors 


d'un appel récursif. 


P-source-récurst f P-objet-ttérattf 
| 
CALCUL 
O —— = = 
TRANSFORMATIONS > O > EXECUTEUR > ITERATIF 
P-source-récurstf 
CALCUL 
O > *EXECUTEUR-VLISP* | —> ITERATIF 


Voici, en exemple la fonction DELETE, livrant de la liste L une copie d'où 
toutes les occurences de 1'élément X ont été éliminées 
CDE DELETE (X L) CCOND 
p Seesama CCNULL L) NIL) 
2 Tne CCEQUAL X CCAR L)) CDELETE X (CDR L))) 
3 -----~---~------- (T (CONS CCAR L) (DELETE X CCDR L)))))) 
Dans la clause 2, l'appel de DELETE sera interprété comme un branchement : ni 
environnement, ni continuation ne seront préservés. 


Dans la clause 3, l'appel de DELETE ne préservera pas l'environnement. 
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Nous avons pu prouver la correction de cette structure d'interpréte, 
en construisant un interpréte abstrait sous forme de régles décrivant, 
pour chacun de ses modules, l'état de la pile de récursion à son 
entrée et à sa sortie, sous la forme d'un mot constitué de ses éléments 
successifs. 
L'élimination de la récursivité se fait alors par filtrage sur ce mot. 
Etant donné la très grande fréquence de tels schémas de programmes en LISP, 
on obtient une économie considérable d'utilisation de pile, qui, dans le cas 


de programmes très arborescents, peut atteindre un rapport de 541. 


1.3.2.2.- Constructions nouvelles : SELF, ESCAPE, MULTIPLE et CLOSURE 


Une conséquence immédiate de ce choix d'interprète est de permettre 


la construction et l'utilisation de plusieurs fonctions originales. 


SELF 


La construction SELF: implémentation directe très simple de l'opérateur point- 
fixe en lambda-calcul, qui trouve lå une utilisation pratique inattendue, en 
permettant de ne pas multiplier inutilement les noms attribués à différentes 
fonctions d'un même programme, et en diminuant le nombre de paramètres à attribuer 
aux fonctions auxiliaires d'une même fonction principale, sans avoir 4a 

délocaliser les variables : la pureté de VLISP est alors préservée. 


Voici en exemple une boucle supérteure itérative utilisant cette construction : 


(LET ©) (PRINT CEVAL-MODULE CREAD))) 
CSELF)) 


Voici un autre exemple d'utilisation de SELF, fusionnant avec 


économie d'arguments une fonction construisant une liste de factorielles 


et une fonction itérative auxiliaire 


(DE FACTLIST CN) 
(LET CCX 0) CR CLIST 1))) 
CIF C= X N) R 
(SELF CADDI X) 
(CONS C CADDI X) CCAR RD PDD 


ESCAPE 


La construction ESCAPE et sa variante affaiblie LESCAPE.ESCAPE est une fonction 
de saut généralisée, implémentation directe d'une construction théorique de 
J.C. REYNOLDS (1972). Cette fonction de sortie est la plus puissante compatible 
avec la structure récursive de VLISP. Apparentée avec les constructions CATCH 
et THROW de MACLISP (MOON 1974,LAUBSCH 1976), on montre aisément qu'il est 

très facile et concis d'exprimer la sémantique de CATCH avec ESCAPE. 

En revanche, il est impossible d'exprimer la sémantique de ESCAPE avec CATCH 
sans devoir modifier la structure de l'interprète lui-même. 

ESCAPE permet de sortir directement de n'importe quel niveau d'imbrication, 
tant statique que dynamique, sans avoir à spécifier la profondeur de cette 
imbrication, et en ramenant une ou plusieurs valeurs qui peuvent être le 
résultat d'un programme complexe encapsulé dans l'application de ESCAPE. 

L'état de l'environnement précédant l'appel de ESCAPE est naturellement 


restitué. 


Voici en exemple la fonction COPY-IF-P, qui livre une copie de l'expression 
E si tous les atomes ayant des occurences dans E satisfont à la propriété P, 


et si ce n'est pas le cas, livre une liste de la forme 
(NOT atome-ne-satisfaisant-pas-la-propriété) 


(DE COPY-IF-P CE P) 
(ESCAPE NO-P 
(COPY-IF-P-2 E))) 


(DE COPY-IF-P-2 (E) 
CIF CATOM E) 
CIF CP E) E CNO-P CLIST "NOT E))) 
(CONS CCOPY-IF-P-2 CCAR E)) 
CCOPY-IF-P-2 CCDR E))))) 
La version affaiblie de cette construction, LESCAPE, permet dans les mémes 
conditions de sortir d'un seul niveau d'imbrication d'appel de fonctions, en 


laissant alors au fonctionnement normal de l'interpréte, le soin de mener 
3 


4 bien la restitution de l'environnement. 
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MULTIPLE 


La construction MULTIPLE est une extension du caractére fonctionnel de VLISP 
et constitue une solution originale au probléme des valeurs multiples 
(FRIEDMANN 1976a, STEELE 1976b, ALLEN 1977). 

Elle permet de ramener une séquence de valeurs comme résultat de l'appel 
d'une fonction. Si cet appel est porté en argument d'une autre fonction, les 
valeurs constituant cette séquence sont alors distribuées et liées séparèment 


à chacun des paramètres formels de la fonction appelante. 


Voici en exemple une autre version de la fonction calculant une liste de 


factorielles 


(DE FACLIST CN) 
(CONS CG NDD) 


(DE G CN) 
CIF (= N 2) (MULTIPLE 1 NIL) 
CLET CCU V (G CSUBL NDD) 
(MULTIPLE (” N U) CCONS U V))))) 

On notera que, si on souhaite effectuer des transformations d'équations 
récursives, la construction MULTIPLE permet l'application directe de la 
règle d'abstraction de BURSTALL (1975, p. 467). 
La construction MULTIPLE ne provoque pas d'overhead appréciable, en ne 
nécessitant pas un traitement spécial (traduction du programme en style 
de passage de conttnuattons (STEELE 1976b) ou composttton verticale 
(FRIEDMANN 1976a)), mais est une conséquence normale de la structure 
de notre interpréte. 
MULTIPLE apporte également une solution élégante a l'implémentation et 


à l'utilisation en VLISP des STREAMS (LANDIN 1966, STOY 1974, BURGE 1975). 


CLOSURE 


Avec la construction CLOSURE, nous donnons une solution en lecture seule, puis 
en lecture-écriture au probléme, traditionnel dans les versions contemporaines 
de LISP, du passage d'arguments et de retour de valeurs fonettonnels, connu 
sous le nom de probléme du FUNARG (MOSES 1970). Il consiste 4 associer une 
fonction à un environnement privé et stable, généralement celui de la création 
de la fonction, cette association prenant alors le nom de fermeture (ou FUNARG 


en LISP 1.5 (McCARTHY 1962c)). 


Notre solution est plus économique que celle de LISP 1.5, en n'associant à la 
fonction clôturée que le sous-ensemble de l'environnement qui lui est nécessaire, 
comme le suggérait (SANDEWALL 1970). Plus important, notre solution en lecture 
seule est compatible avec la structure superficielle d'environnement de VLISP, 
utilisant le principe des vartables fluides, à portée définie dynamiquement, 


qui est celle de toutes les versions contemporaines de LISP. 


La généralisation en écriture de notre solution ne préservant pas la pureté 


de VLISP, en raison des effets de bord, nécessite une extension de VLISP dans 


Ld 


la direction des langages à structure d'ACTEURS (HEWITT 1973, 1974a,b, 1977, 


SMITH 1975). Une telle extension sera présentée au chapitre 5 de cette étude. 


Dans cette extension, un acteur recevant un couple d'entiers positifs, et 
> 


renvoyant un couple composê du quotient de M et N, et de son reste, s'écrira 


CIS $DIV C=> (MSG: [M N] CONT: C) 
CIF CGT NM) 
(C <= (MSG: [0 MID 
(SDIV <= (MSG: [C- M N) NI 
CONT: C=> (MSG: [X YD 
(C <= (MSG: [CADDI X) YIDÐDÐDÐ 
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1.3.3.- VISIONS DE PROGRAMMES : DEVELOPPEMENT ET MISE AU POINT 


Enfin, en conclusion, nous présenterons une discussion des constituants 
nécessaires à la construction d'un système d'aide à la programmation, et 


d'aide à la mise au point, tel que nous l'avons suggéré plus haut. 


L'ensemble des ingrédients qui composeront un tel système est rassemblé 
sous le nom du système VISION. Le concept unificateur qui y préside suppose 
qu'un programmeur introduisant un programme sous éditeur, le faisant interpréter, 
en surveillant l'exécution sous TRACES, FLASHES, MONITEURS, BREAKS et bien 
d'autres outils d'exécution contrôlée, le modifiant pour le mettre au point, 
l'améliorer ou l'étendre, le commentant enfin par divers moyens : plans, 
avertissements, programmes-témoins, voire assertions, ce programmeur donc ne 
fait que considérer un même objet sous différents points de vue ou VISIONS, 


appelées successivement à communiquer. 


Un programme, dans cette perspective, n'est pas un objet statique, 
corvéable et transformable à merci de façon passive, mais tout au contraire 
l'ensemble des VISIONS qu'un programmeur peut en avoir, simultanément ou 


successivement. 


Nous suggerons un mode de communication entre visions par une extension 
du filtrage qui nous a servi de langage de spécification de VLISP : nous 
avons déjà pu dégager dans le langage LISP et la structure de ses interprètes 


quelques unes des caractéristiques de VISION. 


Nous attendons d'un tel système 


1) qu'il facilite la tâche de conception et de mise au point 
du programmeur dans la direction et les circonstances que 


nous avons indiqué plus haut 


2) qu'il rende possible par son emploi ce qui nous semble être 
un préalable impérieux 4 toute suggestion de méthodes de 


programmation, proposées soit comme plus sûres, soit comme 
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plus naturelles : un outil d'enregistrement et donc 


d'observation d'un programmeur au travail. 


Les études empiriques de l'ectivité affective des programmeurs demeurent 
relativement rares (WEINBERG 1971, SCHNEIDERMAN 1975, MEYER 1977) probablement 
pour deux raisons. 

La première tient à une attitude normative assez répandue, par ailleurs très 
compréhensible face à l'urgence de la réalisation de nombreux programmes, et 
aux responsabilités morales et matérielles considérables liées à certains 
d'entre eux. 

La seconde tient à l'absence totale d'instrument d'observation de cette 
réalité empirique qu'est l'activité du programmeur, particulièrement en 
situation interactive. 

Nous attendons du futur système VISION qu'il soit le prototype d'un tel 


instrument. 


1.3.4.- PLAN DE L'ETUDE 


Ainsi notre travail se répartira comme suit 


Au chapitre 2, nous donnons un apercu historique de l'implémentation des 
lambda-interprétes. Nous y examinerons les versions originelles du LISP 
pur et de LISP 1.5, ainsi que les interprètes collatéraux : SECD-machine 


puis GEDANKEN, précurseur des interprétes de type PLASMA. 


Au chapitre 3, les difficultés d'implémentation repérées au cours du 
chapitre précédent sont isolées et examinées dans un contexte plus formel. 
Trois évaluateurs seront présentés successivement, en introduisant plusieurs 
modes d'implémentation de la récursivité, le problème du FUNARG et ses 
solutions, ainsi que les notions et l'utilisation des fermetures et des 


continuations. 


Au chapitre 4, nous présentons la méthode de description d'implémentation 
par filtrage. Notations et algorithmes de filtrage y sont rassemblés sous 


la forme d'un langage de spécification de LISP et ses dérivés : FILTRE. 


Au chapitre 5, FILTRE est appliqué à la description d'un sous-ensemble 
du langage PLASMA compatible avec VLISP, que nous nommerons MICRO-PLASMA. 
Nous y examinerons les notions d'acteurs et de transmissions, et nous 


donnerons en FILTRE l'implémentation complète de MICRO-PLASMA. 


Au chapitre 6, nous étudions systématiquement l'interprète VLISP et son 
implémentation en FILTRE : l'organisation de la mémoire, la structure 
de l'interprète, les principales fonctions classiques et les fonctions 
originales à VLISP. Le chapitre s'achève sur la comparaison de deux 
implémentations de VLISP, et sur la confrontation de celui-ci avec 


MACLISP, LISP 1.6 et INTERLISP. 
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Au chapitre 7, nous étudions en détail comment l'interprète VLISP permet 
l'exécution itérative d'appels récursifs. Après la caractérisation des 
appels récursifs considérés (post-récursifs normaux, mutuels et enve loppés) 
nous explicitons l'abandon dynamique de la récursivité par la donnée des 
algorithmes qui l'induisent, puis nous la justifions au moyen de la 
construction d'un interprète VLISP abstrait. Le chapitre s'achève sur 
l'évaluation comparée de ces interprétations itératives, avec le code 


généré par le compilateur NCOMPLR de MACLISP. 


Le chapitre 8 conclut l'étude, par l'examen des outils de mise au point 
de programmes en LISP et de leur intégration aux interprètes. Nous y 
suggérons un principe unificateur du développement, de la compréhension 


et de la mise au point de programmes,fondé sur la notion de VISION. 


Toute la suite de cette étude suppose de son lecteur une certaine fami- 
liarité avec la programmation récursive en général, et avec le langage 
LISP en particulier. Le recueil de (FRIEDMANN 1974) ainsi que la seconde 


partie de (WINSTON 1977) en sont d'excellentes introductions récentes. 


CHAPITRE 2 


HISTORIQUE DE L’ IMPLEMENTATION DES LAMBDA-INTERPRETES 


Qu'est-ce-qu'un interprète? Un interprète est une définition active. 
Définir une notion, c'est en spécifier sa signification en termes de notions 
déjà connues : de même, un programme interprété est une donnée susceptible 
d'être décomposéeen d'autres données. Définir une notion, c'est également la 
rendre primitive, composable pour le développement de définitions ultérieures 
de même, un programme est interprétable en tant qu'il peut être dynamiquement 
substitué à un autre programme, ou à lui-même dans le cas récursif. La notion 


de procédure est essentiellement interprétative. 


L'activité d'un interprète consiste en décompositions et substitutions 
opérées sur des descriptions de programmes : ces descriptions sont des 
représentations de connaissances concernant des structures de données et de 
contrôle. Ainsi la notion de déclaration est également interprétative : un 
interprète utilise des informations qu'un traducteur aurait fait disparaître. 
L'ensemble de ces informations est la sémantique interprétative du langage 
dans lequel un programme est écrit, et constitue la structure de machine 


s. . ~, (1) “ , we ES o a Ad 
intrinséque au calcul désiré et à ses propriétés. 


(1) Un programme interprété guide et contraint l'interprète dans le choix 
de ses opérations, de la même facon que la grammaire d'une langue 
naturelle contraint un de ses locuteurs. La comparaison s'arrête là 
cependant, car un interprète autorise à l'exécution l'accès tant en 
lecture qu'en écriture à ces informations. 
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Si des considérations d'efficacité ne sont pas prises en compte, on 
observe une curieuse complémentarité entre interprétation et traduction : un 
interpréte réalise une traduction toujours interrompue. Inversement, l'exécu- 
tion d'un programme traduit est une interprétation prématurée : la traduction 
vers un langage-objet est essentiellement réductrice, elle admet une structure 
de machine extrinsèque au calcul et à ses propriétés. Un interprète peut, en 
revanche, réaliser une traduction amplificatrice, dans le cas de la mêta- 
évaluation ou évaluation symbolique, en opérant sur des descriptions d'objets 


Pad + 1 
génériques | 


Si on prend en compte des contraintes d'efficacité, on observe qu'un 
interprète est localement inefficient : conséquence ici des nombreux tests 
nécessaires à la décomposition d'un objet et à la détermination de son sobre os. 
Un interprète peut cependant être globalement efficient, en tirant parti des 
propriétés globales d'un calcul, qu'il est seul en mesure de déceler : nous 
verrons au chapitre 7 que l'exécution itérative d'un appel récursif n'est 
opérable dans le cas général que par un interprète, si on admet, comme c'est 
le cas en LISP, la possibilité de programmes construits et évalués au cours 
d'une exécution. De plus, rien n'empêche, en principe, un interprète de 
conserver une trace des décompositions qu'il réalise, le programme interprété 


en langage-source étant ainsi progressivement traduit en langage-objet au fur 


et à mesure de son interprétation. 


(1) en méta-évaluation d'un programme, une description de donnée est livrée 
au programme méta-évalué, le résultat en est alors une description de ce 
que fait le programme, indépendamment d'une donnée particulière. 


(2) cette contrainte devient moins sévère si cette détermination de genre est 
effectuée par hardware, comme c'est le cas sur ordinateur B5500 
(BURROUGHS 1964, p.6-8) : l'instruction DESC charge dans la pile un 
descripteur de litéral, de tableau ou de procédure. Si le descripteur 
chargé est un descripteur de procédure, celle-ci est aussitôt lancée. 
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Enfin, dans une perspective de développement, l'intérêt majeur des 
interprètes réside dans la souplesse de représentations qu'ils offrent au 
D ne de en permettant de conserver concrètement la liaison conceptuelle 
entre un programme en langage source et ses représentations internes. Dans 
une perspective de mise au point, l'interprétation offre des possibilités 


illimitées de simulations, d'exécutions surveillées et de diagnostics d'erreurs 


actifs. 


(1) Par rapport à un traducteur qui réalise des décompositions une fois pour 
toutes, un interprète autorise des décompositions multiples, correspondant 
à des représentations multiples du même programme. 
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2.1.- ASPECTS GENERAUX ET APPLICATIONS DES LAMBDA-SYSTEMES 


Depuis 1960, une lignée de systémes interprétatifs se définissent 
comme des implémentations, à fidélité variable, du lambda-calcul de CHURCH 
(1941) : LISP pur et LISP 1.5 (McCARTHY 1960a et b, 1962a et c), les SECD- 
machines, ISWIM et McG360 (LANDIN 1964, 1965, 1966a et b, LEAVENWORTH 1969a 
et b, McGOWAN 1970), GEDANKEN (REYNOLDS 1969, 1970), CONNIVER (SUSSMAN 1972a,b, 
McDERMOTT 1974), SCHEME (SUSSMAN 1975), PLASMA (SHROBE 1976, HEWITT 1977), 
DARWIN (STEIGER 1976). 


Leur développement a succédé à des systèmes très innovateurs comme 
IPL V (NEWELL 1961) 7/ mais peu viables, ne dégageant pas nettement le concept 
de procédure, et a coexisté avec un autre courant interprétatif issu du 
langage COMIT (MITRLE 1962), se poursuivant à travers les diverses versions 
de SNOBOL (FARBER 1966), et culminant dans les actuels systèmes de production 
(DAVIS 1975, NEUMANN 1975, GALKOWSKI 1976). Ce dernier courant se définit 


comme l'implémentation d'un modèle de calcul très distinct : les algorithmes 


de MARKOV?” 


Les lambda~systémes se regroupent en deux variétés. Dans la première, 
caractéristique d'ISWIM, McG360 et GEDANKEN, interprètes dits applicatifs dont 
l'unité d'évaluation est l'expresston, application d'un opérateur à des opérandes, 


la mise en oeuvre proprement dite sur ordinateur et les contraintes d'efficience 


(1) Parmi les nombreuses innovations d'IPL V notons l'idée de liste et son 
implémentation, le concept nettement dégagé de la pile et de la P-liste, 
enfin le concept de générateur plus connu aujourd'hui sous le nom de 
STREAM. 


(2) Ce courant a cependant dégagé la notion de pattern-matching, que nous 
nommerons filtrage dans toute la suite de cette étude et dont nous ferons 
grand usage. Cette notion est devenue une composante majeure des langages 
d'Intelligence Artificielle (BOBROW 1974), en introduisant un nouveau 
type d'appel indirect de fonction par filtrage sur base de donnée 
(pattern-directed invocatton)(HEWITT 1972, LEVI 1975). 
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passent au second plan : avant tout outils d'expérimentations conceptuelles, 
ils tentent de donner un modèle opérationnel du lambda-calcul en définissant 
une structure de machine abstraite qui puisse unifier les constructions en 
apparence disparates mises en jeu dans les langages de programmation usuels. 
Ainsi, divers types de transport de données : passages de paramètres, affec- 
tation de variables et de structures, de structures de contrôle : séquentialité, 
imbrication fonctionnelle, récursion, itération, coroutines, backtracking, 
exécution surveillée, de définition et de composition de structures de données, 
sont modélisés sous forme d'expressions du lambda~calcul, et considérés comme 
des abréviations. 

Le caractère principal de ces modèles est leur fonctionnalité : les définitions 
de données et contrôle sont procédurales, une structure de donnée n'y était 
rien d'autre que i ensemble de ses primitives de composition, d'accès et de 


modification de cette structure. 


La seconde variété d'interprétes, issue de LISP,est plus directement 
orientée vers la construction de programmes d'application, essentiellement 
en Intelligence Artificielle. Depuis le début des années 1970, ces langages 


ont permis la construction de programmes tentant 


1) de consulter, de composer et d'étendre des représentations 
de connatssances, rassemblées et structurées de façon très 
flexible dans des bases de données (BOBROW 1977a) 

2) de former des plans d'actions en utilisant ces connaissances 


(HEWITT 1975a) 


Parallèlement aux grands domaines d'application : vision, compréhension d'énoncés 
en langues naturelles, manipulations robotiques, le domaine de la programmation 
(conception, mise en oeuvre, mise au point, compréhension, amélioration et 
maintenance de programmes) est apparu comme un champ d'expériences très fertile. 
Pour étudier les représentations et l'utilisation de connaissances mises en jeu 
en programmation, en vue par exemple de la construction de compilateurs très 
optimisants (STEELE 1976a,b),de nouveaux interprétes SCHEME, PLASMA, DARWIN sont 
apparus, reprenant les préoccupations d'unification fonctionnelle inaugurées 


dans les études sémantiques par LANDIN et REYNOLDS. 
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2.2.— LISP PUR 


Il est relativement peu connu que LISP a été conçu en moins de deux 


~ 


semaines par J. McCARTHY ā l'occasion d'un exercice de programmation 
(BOBROW 1977b). Sa définition officielle, trés concise (McCARTHY 1960a, 
1962c) est essentiellement circulaire : le LISP ae est défini par un 
ensemble de programmes LISP dont les principaux sont EVAL et APPLY, qui 
constituent un évaluateur LISP. 


McCARTHY inaugurait ainsi une double tradition consistant à utiliser 


1) un interpréte pour définir un langage : la sémantique du 
langage est décrite par cet interpréte rédigé dans un 
méta-langage qui évalue des représentations abstraites 
de programmes 

2) le langage défini comme son propre méta-langage de définition 
de tels interprètes sont qualifiés de métactreulatres 
(REYNOLDS 1972, STOY 1974). La compréhension du langage est 
atteinte par un processus itératif dans lequel la compréhension 


qu'on peut avoir de la définition formelle renforce la 


(2) 


compréhension du langage et inversement 


(1) LISP pur est LISP réduit à sa composante applicative. En général, une 
procédure est pure dans la mesure où son comportement ne varie pas avec 
le temps : appliquée aux mêmes arguments, elle retourne toujours la même 
valeur. 


(2) STOY (1974) critique assez vivement ce processus de bootstrapping conceptuel 
en effet des présupposés sur le langage définissant peuvent, au cours de 
l'apprentissage, être reportés sur le langage défini, en particulier en ce 
qui concerne l'ordre d'application (appel par valeur où par nom), et le 
traitement des arguments et valeurs fonctionnels. 

Une seconde critique de ce type de définition, conséquence immédiate de 
la première, se rapporte à l'absence d'indications précises concernant 
l'implémentation, ce qui jette quelques doutes sur l'efficacité du langage 
défini. 
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Nous donnons dans l'appendice | la définition en VLISP du LISP pur défini 


(1) 


p.13 de (McCARTHY 1962c)'°’. 


On y observe que 


1) 


2): 


3) 


4) 


l'interprète évalue directement des structures de données 
qui sont les représentations internes d'expressions LISP. 
Cette évaluation doit mettre en jeu des décompositions 
successives en CAR et CDR correspondant à la décomposition 
en opérateurs et opérandes inhérente au caractère applicatif 


du langage 


l'environnement est défini par une liste d'associations 
(A-liste) noms-expressions. L'occurence des atomes LABEL 

et LAMBDA en tête d'opérande joue le rôle de déclaration (2) 
en induisant des extensions de l'environnement par adjonction 
d'arguments liés à leur valeur dans le cas de LAMBDA , et 
dans le cas de LABEL d'un nom lié à la lambda-expresston. 


Ce dernier cas est la solution donnée par LISP pur à 


l'implémentation de procédures récursives 


les opérateurs ne peuvent être que constants (LAMBDA et 
LABEL expressions, CAR, CDR, etc.) ou valeurs de vartables. 
Ils ne peuvent pas être le résultat d'un calcul d'expression. 
Cet écart à la norme du lambda-calcul, qui assure une 
symétrie totale opérateurs-opérandes, fait de LISP pur un 


~ 


P-évaluateur (cf. §3.4), obéissant à une discipline de pile 


des procédures anonymes (lambda-expressions) ne peuvent pas 
être récursives, sauf à recourir à un opérateur point-fixe 
(cf. 83.3). Une légère modification à apporter à cet interprét 
pour y remédier consiste à incorporer la construction VLISP 
«SELF> (cf. §6.2.10) au LISP pur. Cette modification est 


donnée à l'appendice 1. 


(2) Dans une perspective d'implémentation (STEELE 1976b) le symbole de fonction 
LAMBDA joue le rôle d'une déclaration fixant l'espace de définition des 


variables. 


(1) Nous avons choisi cette version de préférence à celle présentée dans 
(McCARTHY 1960a,b), cette dernière comportant l'erreur relevée par 
(JORDAN 1973) consistant à réévaluer des arguments déjà évalués. 
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5) l'interprète LISP pur est un jeu d'appels corécursifs entre 
EVAL et APPLY. La suite de ces appels n'est bornée que par 
l'évaluation d'une variable dans EVAL 
. l'exécution d'un opérateur primitif (CAR, CDR, etc.) 
dans APPLY 
Une lambda-fonction ne retourne ainsi jamais de résultat, 
mais envoie une valeur 4 une autre fonction : cette autre 
fonction est une continuation, laissée implicite en LISP 
pur. 
Les langages récents visent 4 rendre explicites ces 
continuations implicites. Nous examinerons plus attentivement 


l'usage des continuations au §3.8 


6) a l'exception des formes spéciales : IF et QUOTE, LISP pur 
implémente l'appel par valeur. Cette décision est enterrée 
dans EVAL, lors de l'appel de APPLY, justifiant dans une 
certaine mesure la critique de STOY des définitions 


métacirculaires. 


Enfin, la définition métacirculaire du LISP pur ne fixe pas nettement, à 
supposer que son implémentation à l'aide d'une pile soit devenue apparente 
au lecteur, les conditions exactes de l'emploi de cette ressource, jettant 
ainsi un doute sur l'efficience du langage défini. Dans l'appendice 1 nous 
constatons que les appels récursifs de EVAL 1, APPLY 1 et 5 sont nettement 
itératifs. Les appels EVAL 2 et APPLY 3 sont corécursifs et peuvent être 
également considérés comme itératifs. Enfin les appels de SELF dans EVAL 3 
et APPLY 4 ne nécessitent pas la préservation de la valeur des arguments sur 


la pile. 


Ces aspects assez délicats et intéressant au premier chef les implémenteurs 
sont donc laissés implicites dans la définition du LISP pur. Nous avons tenté 
d'y porter reméde en VLISP en y autorisant des interprétations itératives et 


semi-itératives d'appels récursifs, qui seront examinées au chapitre 7. 


eds LISP. 1s) 
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La plupart de ces aspects du LISP pur se sont conservés en LISP 1.5 


(McCARTHY 1962a,c). Des nouveautés y ont cependant été introduites 


1) 


2) 


3) 


fonctions définies <typées> : l'introduction 
des fonctions typées FEXPR, passant les arguments 
en bloc sans les évaluer, permet à l'utilisateur 


de définir de nouvelles structures de contrôle 


l'attachement à chaque atome d'une valeur globale 
indépendante de l'environnement local, et d'une 
liste de propriétés (P-liste) : suite de couples 
noms-expressions (nommés attributs et valeurs). 
Le <«<type> des fonctions est un attribut repéré 
sur la P-liste de l'atome-nom des fonctions. La 
récursivité est implémentée par attachement à cet 
attribut de la lambda-expression représentant la 


fonction 


l'introduction de la fonction FUNCTION rétablit 
dans une certaine mesure la symétrie opérateur- 
opérande du lambda-calcul. Une fonction enclose 
dans un appel de FUNCTION devient une fermeture : 
association de l'environnement courant et de la 
procédure. Cet environnement clôturé redeviendra 
l'environnement courant lorsque la fermeture sera 
pii Nous examinerons plus attentivement 


la notion de fermeture au $3.7 


(1) (LINDSTROM 1973, 1976) donne plusieurs extensions non-récursives de 
LISP 1.5 par macrogénération, en utilisant largement la fonction 


FUNCTION, 
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4) une composante tmpérative vient complèter l'aspect 
applicatif du langage. Les affectations et les 
branchements y deviennent possibles, ainsi que des 
effets de bords très subtils sur les listes, et donc 
sur les représentations internes de programmes. Des 
structures de données circulaires sont alors autorisées, 


ainsi que l'auto-modification de programmes. 


La définition de LISP 1.5 (McCARTHY 1962c, p.70-71) demeure métacirculaire et, 
de surcroit, ne cie pas la composante impérative. Les difficultés d'implé- 
mentation restent identiques à celles rencontrées en LISP pur : ces difficultés 
ont motivé l'apparition de spécification d'interprètes par définition de 


machines abstraites. 


2.4.- SECD MACHINE 


Introduit par LANDIN en 1964, le type de spécification connu sous le 
nom de S (Stack) E (Environment) C (Control) D (Dump) machine, visait 
essentiellement à modéliser par des lambda-expressions les constructions 
d'ALGOL 60, ces lambda-expressions étant tnterprétées par cet automate 
abstrait. 

Un calcul y est considéré comme une suite d'états successifs, la SECD machine 
réglant les transitions entre ces états : la spécification d'un interpréte se 


présente alors sous la forme modulaire d'un ensemble de régles de production. 


Un état est la donnée d'un quadruplet 
. STACK : pile de valeurs déja calculées 
. ENVIRONMENT : environnement au sens LISP 
. CONTROL : suite d'expressions à évaluer et d'indicateurs d'application 


DUMP : pile d'états préservés et restituables 
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Dans sa forme originale, elle implémente un lambda-calcul restreint avec appel 
par valeur. La restriction est une conséquence de l'arrét prématuré de 
l'évaluation aux fermetures. Comme l'a noté (McGOWAN 1970) l'arithmétique 
lambda-calculatoire ne peut pas y être définie, faute d'évaluation du corps 


des lambda-expressions. 


Une implémentation de LISP pur sous la forme d'une SECD machine est donnée à 


l'appendice 2 à titre d'exemple. 


Le principe de la SECD machine a connu une fortune étonnante, y étaient 


en effet impliqués 


1) la notion de syntaxe abstraite, suggérée par (McCARTHY 
19624) : représentation abstraite des programmes sous 
forme de structures de données qui en livrent la struc- 
ture sémantique essentielle. 


La SECD machine opère sur ces représentations abstraites. 


2) la notion de DUMP : ancêtre conceptuel des contextes de 
QA4 (RULIFSON 1972) et de CONNIVER (McDERMOTT 1975) et 
HBASE (BARROW 1975). La composante dump (état global) 
étant accessible, la possibilité de spécifier des modes 
de calcul de type coroutine et backtracking (LEAVENWORTH 
1969a, 1970, 1971) y est très aisée. 


3) la conception, bien connue des logiciens, d'un calcul 
comme une suite d'étapes : transition d'un état global 
vers un autre état global, est au principe d'un mode de 
calcul interrompu, surveillable, connu sous le nom de 
pas à pas, ou STEPPER (RICH 1976). Le mode pas a pas, 
disponible au niveau hardware sur tout ordinateur est 


introduit ici dès la définition du langage 


4) l'interprète,i.e. la fonction de transition est non-récurstf : 
les structures de contrôle y sont reportées sur les 
structures de données. La fonction de transition se termine 
toujours ,un programme non-terminant réappliquera indéfiniment 


la même suite de productions sans parvenir à un état final. 
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Ce type de définition offre cependant plusieurs inconvénients pour l'implémenteur. 


Tout d'abord, l'interprétation d'une syntaxe abstraite présuppose une traductton, 
préalable au calcul, d'un programme en notation externe par sa décomposition 
et son marquage en éléments sémantiques : ce qui dans le cas de LISP n'est 


guère approprié. 


Ensuite, l'apparence de modularité, conséquence de l'explosion de l'évaluateur 
sous forme de productions indépendantes (états > états) demeure assez artificielle, 
un certain ordre d'application devant être de toute manière assigné à ces 


1) 


Doducbions ; 


Enfin, ce mode de spécification semble moins utile 4 l'implémentation proprement 
dite qu'à la justification d'implémentation. Les règles de vérifications que 
nous proposons au §7.4.2 afin de justifier l'élimination de certaines récursi- 


vités dans VLISP, constituent une variante de SECD machine. 


2.5.-— GEDANKEN 


Avec l'interprète GEDANKEN, J.C. REYNOLDS pousse a ses limites la 
spécification fonctionnelle d'un langage de programmation. A partir d'un 
petit nombre de notions : lambda-expressions, applications,fermetures, 
références, l'ensemble des objets du langage : structures de données et 
de contrôle est présenté sous forme procédurale. 

Définitions et compositions de données y sont spécifiées de façon implicite : 
l'utilisateur peut redéfinir à volonté les procédures qui réalisent ces 


données. 


(1) l'article de 1964 de LANDIN donne la fonction de transition non pas 
sous forme de productions comme (McGOWAN 1970, WEGNER 1968, PLOTKIN 
1975) mais sous la forme d'une procédure d'évaluation très proche 
d'une procédure LISP. 
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De même le flot de contrôle est redéfinissable grace à l'introduction 
de fermetures de programmes (label values) : une séquence d'instructions 
clôturée n'obéit plus à une discipline de structure de blee 5 mais est 
accessible comme une donnée å partir de n'importe quelle de ses composantes. 
Tout point de programme est directement accessible, généralisant ainsi la 


notion de branchement. 


Dans (REYNOLDS 1969), deux interprétes GEDANKEN sont livrés, chacun 
d'eux étant rédigé en GEDANKEN. Le premier (p.48) est une SECD machine 
écrite dans un sous-ensemble de GEDANKEN n'utilisant pas les caractères 
avancés du langage (fermetures de fonctions et de programmes). Pour 
l'implémentation réelle, ce sous-ensemble est traduit à la main en LISP. 

Le second (p. 62) est totalement métacirculaire : une fermeture du programme 


interprété sera représentée par une fermeture de l'interprète lui-même. 


GEDANKEN était ainsi précurseur des interprètes récents fondés sur 
la sémantique des acteurs et du passage de message, PLASMA, SCHEME et DARWIN : 
la symétrie opérateur-opérande du lambda-calcul y était rétablie. Un objet 
y est défini tntrinsèquement par son comportement : l'ensemble des messages 


qu'il peut recevoir et envoyer. 


L'implémentation efficiente de GEDANKEN et des langages de type PLASMA 
pose le problème de la conciliation raisonnable de la structure des ordinateurs 
actuels, implémentant par hardware des "langages" eminemment non-fonctionnels 


avec les principes proposés dans la structure idéale d'un SECD machine. 


(1) (FENICHEL 1971) décrit les difficultés liées aux variables d'étiquettes 
dans les langages à structure de bloc tels que PL/1. 
On y trouvera également une solution, utilisant une horloge temps réel, 
au repérage à l'exécution de l'erreur consistant à effectuer un branche- 
ment dans l'intérieur d'un bloc redevenu inactif. 
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Cette conciliation est actuellement un probléme ouvert. La solution suggérée 
d'une machine acteur (STEIGER 1974, SMITH 1975a) pose pour l'instant plus de 
problémes qu'elle n'en résout. Des solutions partielles ont été proposées, 


nous en examinerons une au chapitre 5. 


Ce rapide, et trés informel tour d'horizon de quelques lambda-interprétes 
a introduit plusieurs notions et problémes : implémentation de la récursion, 
gestion des environnements, traitement des arguments et valeurs fonctionnels, 
choix de représentation de l'opération de substitution essentielle en lambda- 
calcul, fermetures et continuations. 
Les versions contemporaines de LISP en général, et VLISP en particulier, mettent 
en jeu des choix d'implémentation et rencontrent des difficultés et des limitations 
qui ne sont explicables qu'en terme de ces notions. 
Nous allons donc à présent les examiner dans un contexte plus simple et plus 
formel qui nous permettra d'apprécier plus exactement quelles sont les 
limitations des langages interprétés qui sont les conséquences directes de 


ces choix d'implémentation. 
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CHAPITRE 3 


ENVIRONNEMENTS ET RECURSIONS DANS LES LAMBDA-INTERPRETES 


3.1.- PRESENTATION ET DOMAINE D' INTERPRETATION 


Nous allons définir successivement trois structures de lambda-interprétes 
opérant sur un domaine trés simple. Ces définitions seront essentiellement une 
reformulation, dans le contexte de LISP et de ses problèmes d'implémentation, 
des interprètes décrits dans (WARD 1974, DERTOUZOS 1974). 

On insistera sur l'aspect mécaniste de ces définitions : la sémantique 
du lambda-calcul en est totalement absente. Nous sommes principalement inté- 
ressés par les problèmes posés par la construction d'évaluateurs d'expressions 
-applicatives, et par les règles de calcul qui les constituent. C'est dans cet 
esprit que seront introduits les notions et les problèmes posés à 1'implémen- 


teur par 


1) la réalisation de la récursion dans les lambda-interprétes 

2) l'équivalent opérationnel de l'opération de substitution 
en lambda-calcul : l'environnement et ses différents modes 
de gestion 

3) le traitement des variables libres 

4) les valeurs et arguments fonctionnels, introduisant les 
problémes de FUNARG 


5) les fermetures et les continuations. 


La succession des trois interprétes : N-EVAL, P-EVAL et F-EVAL est caractérisée 
par l'introduction progressive de nouvelles structures de données : environne- 


ments et fermetures. 


L'abus de langage consistant à employer le terme de fonction lå où, à stricte- 
ment parler, on a affaire à des procédures est une conséquence de la termino- 
logie LISP, devenue tout à fait co-naturelle aux mécanismes intellectuels de 
l'auteur. L'orientation résolument mécaniste de ce chapitre aurait rendu de 


toute manière cette distinction un peu artificielle. 
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LE DOMAINE D'INTERPRÉTATION 


Les interprétes qui vont suivre opérent essentiellement sur des 
expressions LISP restreintes aux lambda-expressions augmentées d'opérations 
sur les nombres entiers, et d'une forme simplifiée d'expression condition- 


nelle. 


Définissons l'ensemble E des expressions applicatives qui seront 
traitées par ces interprètes | 

1) x €N est dans E 

2) les constantes t (pour vrat) nil (pour faux) sont dans E 


3) les opérations primitives : +, -, addl, >, etc. sont dans E 


Nous nommerons OPRIM l'ensemble de ces opérations. 
4) les lambda-expressions 
(x Utste-de-vartables e € E) 


sont dans E 


Soit LAMBDA l'ensemble de ces expressions 
5) les applications 


(£ € E e € E) 


et 


Œ@eË erie E e2eË) 
sont dans £ 


Soit APPL l'ensemble de ces expressions 
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Nous désignerons par op [el, ..., en] l'application de l'opération primitive 
Op aux expressions el, ..., en. 
EXEMPLES 


+ [3 , 4] > 7 
LS se 2) sg 


Enfin Sel, e2, e3) désignera le résultat obtenu en substituant l'expression 


el a4 toute occurence libre de e2 dans e3. 


3.2.- N-EVAL : UN LAMBDA-INTERPRETE A SUBSTITUTIONS TEXTUELLES 


Voici à présent le premier interprète : N-EVAL. 
Il implémente la beta~réduction en ordre normal (appel par nom) avec les 


Simplifications suivantes 


1) l'expression à interpréter ne doit pas comporter de 
variables libres, ce qui a l'avantage de ne pas poser 
de problème de redésignation (alpha-conversion), et de 


simplifier considérablement le mécanisme de substitution 


2) il y aura arrêt de l'évaluation aussitôt qu'une lambda- 


expression sera atteinte 


3) il n'y aura jamais d'évaluation de variables : la substi- 
tution S étant textuelle, les problèmes d'environnement : 


seront tout à fait absents dans N-EVAL. 


N-EVAL est équivalent, aux restrictions | et 2 près, aux lambda-machines 


classiques décrites dans (WEGNER 1968, McGOWAN 1972, HENDERSON 1973, MICHEL 1976). 


WA Seer ose Seine wet ee ee mo ne a 


ST RL tte rd -a 


36 ets — 


N-EVAL Cx] = 


l. st x EN U Ít , nil} UV OPRIM YU LAMBDA alors x 


2. si x € APPL avec x = (f e) ou x = (f el e2) 
alors 
LÉ st fE {t , nil} alors N-EVAL [el] 
OU N-EVAL [e2} 
selon f 
i. st £ € OPRIM alors f [N-EVAL tej] 


ou f [N-EVAL ceia , N-EVAL (e213 


a st f © LAMBDA avee £= (À (v) corps) 
FAÈRE N-EVAL ts (e , v , corps)] 
6. st f € APPL leve 


N-EVAL c(N-EVAL [f] e)] 


sinon erreur 


stnon erreur 
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3.3.—- RECURSION DANS N-EVAL 


Dans N-EVAL, les lambda-expressions jouent naturellement le rôle des 
procédures. Or, la syntaxe des expressions applicatives traitées par N-EVAL 
nous interdit de tenter d'évaluer des expressions comportant des variables 
libres. 

Ainsi, N-EVAL ne nous permet pas d'utiliser le mode familier de définition 
de procédures récursives, par autoréférence, car le nom de la procédure 
apparaîtrait dans le corps de la lambda-expression comme une variable libre. 
La notion d'environnement étant de N-EVAL absente, et du même coup étant 
exclue la possibilitéde nommer une procédure, le problème est de rendre 


récursives des procédures anonymes. 


UNE CONVENTION DE NOTATION 


Nous emploierons constamment la notation suivante, pour exploiter 
des caractères pertinents de lambda-expressions sans avoir à les écrire 
en totalité 

anc =les-argyments _, 
A LIBRE=les-variables-libres 
=la-variable-libre-de-recursion 


La distinction entre LIBRE et REC n'est faite que pour la commodité 


de la lecture. 


Exemple : 


ARG=X 


À sde (À (x) ((= x 0) 1 (x x CE C x 1))))) 


REC=f 


Considérons par exemple la fonction PARITE, ramenant O si son argument 


x est pair, I sinon. 


= CCR CCR) R ER 


À AEC=S df 
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L'application de À 2 a un argument, par exemple 5 donnera 
REC 


(ne De N-EVALIG (- 5 2))1 
N-EVAL t (N-EVAL Is] © 5 2))) 


> erreur 


v? 


La variable libre s se retrouve argument de N-EVAL, produisant l'arrêt du 
calcul sur une erreur. 
Notre problème est alors, étant donné une procédure he de construire une 


: 9 - “ee . 
expression ae qui permette la récursion. 


c 
ae . , [es + 02 ry 
Toute stratégie de construction de boeg devra tenir compte du fait bien 


connu que l'évaluation de certaines expressions est non-terminante. 


— e we 0e oree may 


CCA (x) (x x)) QO O) O y))) 


Ainsi notre statégie consistera à produire une expression conditionnelle 
qui aura à l'évaluation un comportement non-terminant tant qu'une valeur 


déterminée à l'avance de l'argument n'aura pas été atteinte. 


3.3.1.- UNE PREMIERE STRATEGIE : PAR ALTERATION 


Se REE a te en ee ee ee ee ee ee ec ee ee ee ee AE iph ee ee ee ” AR ee ee 


Elle consistera à modifier profondément ee 


1) en lui adjoignant un argument supplémentaire : la variable 
libre s , qui devient du même coup liée 


2) en modifiant tous les appels de s internes à ee 


(s argument) devenant (s s argument) 
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Reprenons notre fonction PARITE ainsi traitée 


O 


(à (s x) (œ 2 x) x (s s (- x 2)))) 


rec=s df 
l'expression initiale fournie à N-EVAL sera 
CA N 5) 


REC REC 


Et par abstraction de 1'argument, nous obtenons 1'expression cherchée 


seg (A (y) qe Nee y)) 


Si nous faisons tourner 


oO oO oO 
(s 5) ©& (gec ARec 5) 
(rec Rec 2) 
sé nce. “eee. 12 


Reste que cette stratégie demeure très lourde, et nous n'avons pas de 
garantie de pouvoir la reproduire sur un noyau A, quelconque (DERTOUZOS 


1974). Nous chercherons une stratégie plus générale. 


3.3.2.- UNE SECONDE STRATEGIE : PAR PROTECTION 


Dans cette stratégie, nous ne voulons pas modifier notre expression 
initiale, mais nous souhaitons obtenir un «constructeur» qui, pour une lage 
. ? * o A + 
quelconque, nous livre L'expression an permettant la recursion, en 


protégeant ne d'une évaluation prématurée. 


4Q 


Nous utiliserons les définitions suivantes 


DEFINITIONS 


1) Un point-fixe d'une fonction s est une expression x 


telle que (s x) ©& x 


2) Un opérateur point-fixe est une expression Y tel que pour 


toute fonction s , (Y s) est un point fixe de s. 


3) A toute expression de type has , on associera l'expression 


} “df ee) À aec=s) 


telle que, pour une expression g quelconque 


(A 8) as \REC =g 


Il nous faut trouver un g tel que 
(g argument) P> COXA g) argument) 


Cette expression g, point fixe de À sous N-EVAL sera 


Pal + ~ , o wt 
précisément l'expression oe recherchée. 
| c 


Cette propriété de g va nous assurer un calcul tout 4 la fois répétitif 


et terminant. 


EMAL Oe Home er nnd ce tee eer mem eee 
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Reprenons notre exemple de la fonction PARITE 


À pe (XK (s) Q (x) (œ x 2) x (s C x 2))))) 


(g argument) D (A g) argument) 


O REc=g argument) 
(O (x) (œ x 2) x (g (- x 2)))) argument) 


> ((> 2 argument) argument (g (- argument 2))) 


H 


Et deux cas se présentent ici 


1) si argument < 2 
> argument i.e. I ou 0 
2) si argument 2 2 


> (g (- argument 2)) 


Ce qui nous renvoie à l'expression par laquelle a débuté notre calcul, 


avec argument modifié, et il en sera ainsi jusqu'à ce que argument devienne < 2. 


Il nous reste ā présent ā «micro-programmer» une expression qui, jouant le 
rôle d'un opérateur point-fixe, nous livrera l'expression g cherchée, point- 


fixe de À sous N-EVAL. 


3.3.3.- CONSTRUCTION DE g 


+ fait fæ SS ge ee él we me 


Nous savons que l'expression (A (x) (x x)) appliquée a elle-même est non- 


terminante. 


1) Par extraction du corps de cette expression : (x x) nous allons donner 
à x une structure telle que 
(x x) > (À (x x)) 
ou, appliquée à un argument 


((x x) argument) © (CA (x x)) argument) 
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2) Par abstractton de x nous obtenons 
CA Ox) CA (x x))) 
qui appliquée à elle-même donnera : 
(A COA Cx) OA (x x))) O (x) OA (x x))))) 


L'expression (x x) se trouve ainsi protégéeen devenant argument de A, 
S 


-1.e. non immédiatement évaluable. 


3) Par abstraction de À nous obtenons 
| S 


OX Cy) COA (x) (y (x x))) QA (x) (y (x x))))) 


qui est précisément l'opérateur point-fixe Y, i.e. le «constructeur» 


recherché. 


En effet, en nous souvenant que 


NYE (A (s) à ) 


df REC=S 


Nous obtenons 


(Y à) = (CA (y) COA (x) (y (x x))) OA (x) (y (x x))))) A) 
> ((à (x) Or (x x))) Q (x) (A (x x)))) 
> CA (CA (x) Or (x x))) Q (x) CA (x x))))) 


et en abrégeant (x (x) Q (x x))) ar À 


p> 
REC=(a a) 


= (A (Y 2)) 


et l'évaluation s'arrête, N-EVAL utilisant l'appel par nom. 


En reprenant l'exemple de notre fonction PARITE, nous obtenons 


(CY À) argument) = (À argument) 


REC=(a a) 
> ((> 2 argument) argument ((a a) (- argument 2))) 
et si la condition d'arrét n'est pas satisfaite 

> ((a a) (- argument 2)) 

> (CA Ca a)) (~ argument 2)) 


> CA (- argument 2)) 


Rec=(9 a) 
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Le constructeur Y, qui donne le point fixe g = (Y À) de À est connu en 
logique combinatoire sous le nom de combinateur paradoxal (MORRIS 1968, 
CURRY 1972 p. 154). 

Il nous a permis, par l'intermédiaire de l'expression À de rendre récursives 
les procédures Ace de N-EVAL. 

Nous proposerons en VLISP au §6.2.10 la construction SELF qui donne, pour 
toute fonction définie, son point fixe et permet ainsi de rendre récursives 


des fonctions VLISP anonymes. 


Toutefois, il est clair que cet opérateur Y ne fonctionne que dans la mesure 
où l'expression (aa) n'est pas évaluée, mais est substituée textuellement 
dans le noyau or a l'ex-variable libre s : le bon fonctionnement de 
Y dépend du fait que N-EVAL implémente l'appel par nom. 

Nous allons voir que Y ne fonctionne pas pour des lambda-interprétes plus 


efficients, implémentant l'appel par valeur, pour lesquels d'autres formes 


que nous dirons protégées de l'opérateur point-fixe seront nécessaires. 


3.4.- P-EVAL : UN LAMBDA-INTERPRETE A ENVIRONNEMENTS 


L'interpréte N-EVAL que nous venons de décrire ne pouvait pas servir 
de base 4 des interprétes utilisables, essentiellement pour des raisons 
d'efficactté : en effet l'ordre normal mène à la réévaluation des expressions 
passées en argument toutes les fois que leurs copies substituées se retrouvent 
soumises à N-EVAL dans le corps de Fonction ~ 

Une solution possible, préservant la possibilité de mener un calcul 


terminant, quand bien même des arguments non-terminants seraient présentés 


est l'appel par nécessité (VUILLEMIN 1974, AIELLO 1976c). 


(1) autant de fois que nécessaire et quelquefois jamais : si l'argument n'a 
pas d'occurence dans le corps de procédure. 
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Toutefois une objection plus grave se présente å cet aménagement de l'appel 
par nom : il empêche l'évaluation itérative des fonctions post-récursives 
(SUSSMAN 1975, GREUSSAY 1976b). 

Enfin, la substitution textuelle, quelque soit le mode d'appel : par nom, 
par valeur ou par nécessité, ne permet pas de réaliser d'effets de bord en 


rendant impossible toute affectation ou manipulation de pointeurs. 


Pour ces raisons des modifications drastiques doivent être administrées a 
N-EVAL pour modéliser des interprètes tels que LISP pur (McCARTHY 1962c), 
LISP 1.6 (QUAM 1972), MACLISP (MOON 1974), VLISP,et INTERLISP (TEITELMAN 
1976). | 


Les modifications les plus notables doivent être 


1) le passage de l'ordre normal (appel par nom) à l'ordre applicatif 
(appel par valeur) : évaluation des arguments des applications avant 


l'application de l'opérateur aux opérandes. 


2) abandon de la substitution textuelle qui serait ici celle du 
résultat de l'évaluation aux occurences des paramètres formels dans 


le corps des fonctions. 


Cet abandon amène à conserver ces résultats dans une structure de donnée 
consultable et modifiable : l'environnement. Dans l'interprète que nous allons 
décrire, cette structure de données sera représentée comme un ensemble ordonné 


d'associations noms - expressions , consultable par le microprogramme. 
VALEUR Lun-nom , un-environnement ] 


dont l'activation donnera comme résultat l'expresston associée au nom dans 


l'environnement, faute de quoi le calcul s'arrêtera sur une erreur. 


Un nouvel environnement sera construit par le microprogramme 
LIER [un-nom , une-expresston , un-environnement ] 


qui procède par adjonction à l'environnement donné en argument de l'association 
nom — expression. 
Enfin, à la classe E des expressions traitables par N-EVAL, il nous faut ajouter 


la catégorie des variables : VAR. 
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La gestion des environnements qui va être décrite est naturellement conçue 


comme une gestion de pzle. Les objets placés dans la pile seront les associations 
noms — expressions 


L'opération d'empilement sera représenté par 


LIER [nom , expression , environnement | | = environnement, 


En effet, nous devons faire l'hypothèse sur le micro-programme VALEUR que la 

recherche d'un nom doit se faire dans un sens déterminé : plusieurs occurences 
du même nom étant possibles dans l'environnement, l'expression correspondante 
retournée par VALEUR sera celle placée par la plus récente activation de LIER. 
De même, LIER placera la nouvelle association en tête de l'environnement, . 
C'est cette propriété de LAST-IN-FIRST-OUT qui détermine les propriétés 


de pile de notre gestion. 


L'opération de dépilement sera représentée par un retour à environnement. 


Nous noterons la pile vide par A. 
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P-EVAL [x , ENV] = 


lig st XEN U Ct , nil} UV OPRIM UV LAMBDA alors x 
2: st x € VAR alors VALEUR [x , ENV] 
3; st x € APPL avee x= (£f e) ou x= (f el e2) 

alors 


sinon 


si fE lt, nil} alors P-EVAL Cei , ENV] 
| OU P-EVAL [e2 , ENV] 


selon f 


st f € OPRIM alors £ [P-EVAL fe , ENV] 


pu £ [P-EVAL tei , ENVI , P-EVAL [e2 , ENVI) 


st f € LAMBDA avee f= (À (v) corps) 


alors 


P-EVAL Leorpes 4 LIER TY 4 P-EVAL fe , ENV] , ENV)! 


st f € APPL U VAR alors 
P-EVAL L(P-EVAL [£ , ENV] e) , ENV] 
sinon erreur 


erreur 
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3.5. — RECURSION DANS P-EVAL 


Comment réaliser la récursion dans P-EVAL? 


L'opérateur Y valide pour l'interprète N-EVAL sera ici ineffectif, en raison 
de l'ordre applicatif. 


En effet l'appel par valeur induit la dérivation interminable 


((Y À) argument) > COA (Y À)) argument) 
> (CA CA (Y A))) argument) 


> etc. 


dérivation de (Y À} par P-EVAL 


meam eee e e on RE a — § -m mn es p e 


Q (s) à ) 


En nous souvenant que | 
u UV q À AEC =s 


“df 


et en utilisant l'abréviation 
a 


"af Q (x) (y (x x))) 


nous obtenons la dérivation 


P-EVAL [(Y A) , A} = P-EVAL [((A (y) (a a)) À) , Al 


> P-EVAL [(a a) , LIERLy , À , AlJ=envl] 

> P-EVAL [(y (x x)) , LIER [x , a , env! J=env2/ 

> P-EVAL L(A (x x)) , env2] 

> P-EVAL [A … » LIER [s , P-EVAL L(x x) , env2] , env2]] 
> P-EVAL [A  __ , LIER [s , P-EVAL [(a a) , env2] , env2JJ 
> etc. = 


P-EVAL réévalue indéfiniment l'expression (aa) , imbriquée à chaque 


étape dans une nouvelle activation de LIER, 
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3.5.1.- UNE SOLUTION PAR PROTECTION 


ere Mem ne dot ey ee ie ele der ee ee ee ee 


Il convient alors de construire un nouvel opérateur YV, mieux adapté 
à l'ordre applicatif, qui aura pour P-EVAL les mêmes propriétés que Y pour 
N-EVAL. 

La solution au probléme fait une fois de plus appel au mécanisme de 
protection consistant à envelopper l'expression non-terminante dans une 
lambda-expression, par abstraction. 

Cette opération de protection est l'application inversée de la ETA-régle 


en lambda-calcul (CURRY 1958) : 


(A (z) (M z)) LR 


si z n'est pas une variable libre dans M. 


Dans Y , l'expression non-terminante est (x x). 


La solution consistera ici à l'envelopper dans l'expression 


(A (z) ((x x) z)) 


La construction de YV s'en déduit 


Or Cy) COA (x) Cy O (z) (x x) 2)))) Q (x) (y Q (z) ((x x) 2)))))) 


par substitution de (à (z) ((x x) z)) à (x x) dans Y. 


L'expression (x x) est ainsi protégée d'une évaluation prématurée puisque la 


P-EVALuation de l'expression 
e = (A (z) ((x x) z)) 


redonne e sans évaluer le corps de eœ 


dérivation de (YV À) par P-EVAL 


—_- FF om A eee ære mær Ss — Cad —— — 7 


YV est un opérateur point-fixe pour P-EVAL. 


En utilisant l'abréviation 
a “dr (A (x) Cy (CA (z) (Cx x) z)))) 


nous obtenons la dérivation : 


P-EVAL [(YV A) , AJ > P-EVAL [Ca a) , LIER ly , À , Al=envi] 
> P-EVAL [(y (A (z) ((x x) z))) , LIER [x , & , envi J=env2] 
> P-EVAL [OA (x (z) ((x x) z))) , env2] 
>  P-EVAL LNs Cay HEC: BY: 2 env2 | 
> 


ec (z) ((x x) 2)) 
(A (XV AD) 


et l'évaluation s'arrête car l'expression (x x) est protégée d'une évaluation 


prématurée et non-terminante par son imbrication dans 


(A (z) ((x x) z)) 


C'est l'opérateur YV qui est utilisé dans les modèles de calcul réalisant 
l'appel par valeur, en particulier les divers types de SECD machines 


(LANDIN 1964, BURGE 1975b, PLOTKIN 1975). 


3.5.2.- UNE SOLUTION PAR LIAISON DANS L'ENVIRONNEMENT 


Se p a le ee sn FR re Re es te cee te ct ce, ee ci GUN ce ee er te ee ee ee ee ee ee ee i a ee ee ee ee ee 


La construction d'un opérateur point-fixe par P-EVAL n'a été décrite 
que par souci de complétude, et pour illustrer le mécanisme de protection 
fourni par la ETA-rêgle. L'introduction des environnements, et du même coup 
des vartables dans les expressions dérivables, autorise un mécanisme plus 
simple qui consiste pour une procédure À à lier la variable libre s 


REC =S 
à la procédure dans l'environnement. 
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LA [e . . + La Ud 
L'expression s qui livre le point fixe d'une fonction Ares 


est alors trés simplement : 


Q 


s = (À (y) (QA (s) (s y)) à )) 


REC =5 


(s y) sera évaluée dans un environnement où y est liée à la valeur de 
l'argument à l'appel, et s est liée à Nopeaa“ 
La circularité qui était produite dynamiquement, par les opérateurs Y et 

YV est ici l'effet de l'implémentation circulaire d'une structure de donnée 


spécifique : l'environnement, qui comporte alors l'association 


PT 


Le-nom s —+ /-expresston 
REC =S 


Le principe de cette implémentation circulaire explique pourquoi il est 
quelquefois périlleux, en mise au point de programmes LISP de demander 
l'impression de l'environnement. 

Cette solution a encore l'inconvénient de ne pouvoir rendre une procédure 
récursive, sauf à lui donner un nom, ce qui dans la pratique peut parfois 
devenir fort contraignant. C'est encore la construction VLISP SELF qui 


sera au §6.2.10 proposée en remède à cette difficulté. 


La solution encore plus simple 


o 


s = ((A (s) 8) Agee ug? 


ne fonctionnera pas correctement pour P-EVAL. 

Cette solution serait celle implémentée en langage-machine, par modification 
d'un environnement global par une simple affectation de la variable s. 

Par environnement global, il faut entendre un environnement dans lequel une 
seule occurence d'un nom est possible, et où seule l'association la plus 
récente est prise en compte (cette association étant réalisée par effet de 
bord, modification physique de l'ancien et non construction d'un nouvel 


environnement). 
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Cette derniére solution est ineffective pour P-EVAL, en raison de la gestion 
dynamique, en mode de pile des environnements. Cette gestion implique la 
fluidité des variables : l'évaluation s'arrêtant au niveau des lambda- 
expressions, les variables libres de la procédure pourront avoir différentes 
valeurs selon l'environnement courant au moment de l'évaluation de ces 
variables. 

La nature de l'environnement pour le corps d'une procédure est déterminée au 
moment de l'application et non au moment de la définition : une variable libre 
est ainsi évaluée dans l'environnement de l'appelant. 

Cette situation est source d'un ensemble de difficultés liées aux P-évaluateurs, 
rassemblées sous le nom de problème du FUNARG que nous allons examiner au § 


suivant. 


3.6.- LE PROBLEME DU FUNARG 


C'est en LISP qu'a été introduite pour la première fois dans les langages 
de programmation la possibilité de valeurs fonctionnelles. Des variables peuvent 
avoir des occurences libres dans le corps de ces fonctions-valeurs. La détermina- 
tion de la liaison correcte de ces variables libres, en rapport avec le mode 
d'implémentation des environnements, a fait surgir le probleme du FUNARG 
(WEIZENBAUM 1968, MOSES 1970, SANDEWALL 1970, ALLEN 1977). 

Celui-ci s'est historiquement posé avec la décision de ne plus implémenter 
en LISP l'environnement en rassemblant les associations variables~valeurs sous la 
forme d'une structure de donnée : la A-liste. Le rassemblement de ces associations 
permettant de les manipuler en bloc. 

A partir de 1967, en BBN LISP (BOBROW 1967), les environnements ont ete 
principalement implémentés en rendant mutuellement indépendantes les associations 
variables-valeurs, en admettant que toutes les variables étaient a priori globales. 
Lorsque ces variables étaient argument de fonctions, leur valeur précédant un 
appel est préservée dans une pile. Leur nouvelle valeur leur est affectée 
globalement. Puis, au retour de la fonction, leur ancienne valeur leur est 
restituée également par affectation : ce type de liaison de valeur a été 
nommée liaison superftctelle (shallow binding). 

Par ailleurs, le probléme du FUNARG était inhérent 4 la définition de 
LISP «pur» (McCARTHY 1960a et b, 1962c). Même à être rassemblées dans une 
A-liste, les variables étaient fluides : LISP pur n'ayant pas autorisé ni 
défini l'évaluation des lambda-expressions (a ne pas confondre avec leur 
application). LISP 1.5 (McCARTHY 1962c) offrait dans une certaine mesure 
un palliatif à cette carence sous la forme d'une fonction spéciale d'évaluation 
de lambda-expression : FUNCTION. 

Reste que le mode de liaison superficielle des variables s'est imposé 
comme la norme en LISP dans ses versions contemporaines LISP 1.6 (QUAM 1972), 
MACLISP (MOON 1974), VLISP, INTERLISP (TEITELMAN 1976) adoptant une solution 


intermédiaire, en linéarisant la A-liste dans une pile. 
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Cette norme s'est imposée, non pour des raisons de simplicité 
d'implémentation (préservation et surtout restitution des valeurs de 
variables mettant en jeu des mécanismes plus délicats qu'en LISP pur 
ou LISP 1.5), mais essentiellement pour l'efficacité qu'elle permet 
la valeur d'une variable peut être obtenue à une indirection près, 
en contraste avec le passage en boucle et tests inhérents à l'exploration 
d'une A-liste. 

C'est avec les nouveaux langages dérivés de LISP, langages 
d'Intelligence Artificielle, QA4 (RULIFSON 1972), CONNIVER (SUSSMAN 1972a, 
b, McDERMOTT 1974), puis avec les langages de type ACTEURS, PLANNER 73 
(HEWITT 1974a), SCHEME (SUSSMAN 1975), DARWIN (STEIGER 1976), PLASMA 
(HEWITT 1975, SHROBE 1976) qu'un renouveau d'intérét s'est marqué pour 
les environnements de type A-liste. Au prix toutefois d'une importante 
perte d'efficacité qui ne leur garantit pas, pour les grands programmes 
d'application, la fortune qu'a pu connaître LISP depuis 1967. 

Aussi bien plusieurs faiblesses de LISP sont liées à sa nature de 
P-évaluateur, soulevant des difficultés que nous nous proposons à présent 
d'examiner. 

Les P-évaluateurs ont réintroduit la notion de variable, et de 
liaison de variable dans un environnement. Toutefois, plusieurs noms 
identiques peuvent se trouver dans l'environnement associés avec des 
expressions distinctes. Cette ambiguité structurale (plusieurs objets, 
un même nom) introduit les difficultés connues en LISP sous le nom de 
problème du FUNARG (functional argument). 

Contrairement aux langages de programmation ordinaires, les 
lambda-interprétes traitent les fonctions comme des «citoyens de première 
classe» pour reprendre l'expression de Christopher STRACHEY (1967), au 
même titre que des données telles que les entiers : un citoyen de première 
classe est susceptible d'être représenté i.e. variabilisé, passé en argument, 
affectable, valeur d'expression, retourné comme résultat d'une fonction. 
Des fonctions comportant des variables libres peuvent être présentées en 
argument à d'autres fonctions. De même, des fonctions comportant des variables 
libres peuvent devenir les valeurs d'autres fonctions. 

Ces deux circonstances induisent les deux problèmes connus respectivement 


sous le nom de FUNARGs descendants, et FUNARGs ascendants. 
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3.6.1.- FUNARGS DESCENDANTS 


Le phénomène se produit lors du passage de fonctions en argument. 
L'exemple de situation de FUNARG descendant qui suit est du à (DERTOUZOS 
1974). 


Considérons en VLISP les fonctions 


CDE P CF Y CF Y)) 


CDE S CY) 
C+ CP TC CX) (+ X YD) 2) YD) 


L'appel CS 1) provoquera l'évaluation 


CS De (+ CP "CA CX) (+ XY D) 2) 1) 
> C+ COA CX) (+ X 2)) 2) 1) 
m (C+ 4 1) 
> 5 


La variable Y, libre dans (à CX) (+ X Y)) et a valeur | dans le corps de S 


a été masquée par la reltatson de Y a 2 lors de l'appel de P. 


Ce phénomène est la conséquence de la fluidité des variables dans les 
P-évaluateurs : seule la liaison la plus récente d'une variable dans 


l'environnement est prise en compte. 


On constate une discrépance notable avec N-EVAL, qui sur cet exemple aurait 
donne : 
CA (y) (+ A (Ey) € y) AG) (+ x y)) 2) y)) D 
> (+ (OX CE y) (£ y)) QO (x) (+ x 1)) 2) 1) 
(+ (CA (x) (+ x 1)) 2) 1) 
(+ 3 1) 
4 


V VY 


are a A m re ie a 
ee ee 


Décrivons à présent le problème dans sa généralite. 


DEFINITION 


Un probléme de FUNARG descendant se produira toutes les fois que sera 


P-évaluée l'expression 
CRETE m) 


et que le corps de À, contiendra 


ARG=xX XX ,Y | 
(A, 1 n-1 a, -.. q, ) 
et qu'un des arguments q; de À, contiendra 
LIBRES Y 
3 
i | i ` ARG =y 
une fonction quiBRE=Y est passée en argument a À, dans laquelle la 


variable y est liée. Or la variable y de PARA devrait être liée à 


l'argument m de À, qui est un couple plus ancien dans l'environnement, 
et se retrouve en fait liée à q, » cette dernière association étant la plus 


récente. 
Résumons nous par le squelette d'exemple suivant : 

(CX (y) (QO (y) corps) (A (...) y)) ) m) 
L'expression (À (...) y) devrait protéger la valeur m pour y. 


Cette protection sera réalisée dans le troisième interprète F-EVAL que nous 


décrirons au $3.7 grâce au mécanisme des fermetures. 
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On notera que la fluidité des variables dans les P-évaluateurs interdit le 
style de programmation par passage de continuattons, que nous décrirons au 
§3.8 et de ce fait, introduit des difficultés pour la construction de systémes 


de mise au point. 


Nous proposerons au §6.2.11 une solution partielle à cette difficulté en 


implémentant un mécanisme de fermeture en lecture seule dans le P-évaluateur 


VLISP. 


3.6.2.- FUNARGS_ASCENDANTS 


Le phénomène se produit lorsque des fonctions sont retournées comme 


valeurs d'autres fonctions. 


DEFINITION 


Un problème de FUNARG ascendant se produira toutes les fois que sera 


évaluée l'expression 


RG =S 
e = (f m) n) 
et que l'évaluation du corps de À. retourne une expression 


LIBRE =S 
À 


a 


En effet, lorsque se produira l'évaluation de 


(A LIBRE =S n) 


la liaison de s à m aura disparu de l'environnement. 
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L'évaluation produira alors 


1) ou bien une erreur par absence totale de s dans 
l'environnement 

2) ou bien la variable s sera évaluée dans un environ- 
nement global à l'expression e , ce qui n'est pas 


l'effet recherché. 


Afin d'illustrer le phénomène, 


considérons la P-évaluation de l'exemple suivant 


e = (((à (s) (A (x) (s x))) addl) 3) 
P-EVAL [e , A] P-EVAL [ (P-EVAL [ (A (x) (s x)) , LIER is , addi , A J=envi] 3) , À 
P-EVAL [L((A (x) (s x)) 3) , A] 
P-EVAL f(s x) , LIER [x , 3 , A J=env2] 
P-EVAL [ (VALEUR [s , env2] x) , env2] 


VV V V NV 


erreur 


On constate que l'environnement envi , dans lequel la variable s est liée à 


addd! a disparu au moment de l'évaluation de (s x). 


Discrépance encore ici avec N-EVAL qui aurait produit 


N-EVAL fe] © N-EVAL [((à (x) (addl x)) 3)4 
> N-EVAL [(addl 3)] 
> 4 


Or notre exemple ne représente rien d'autre que la mise sous forme de CURRY de 


(à (s x) (s x)) 


~ 


transformation par laquelle, en lambda-calcul, une fonction à n-arguments 


(A (xl ... xn) corps) 
doit être considérée comme l'abréviation de 


(à (x1) (à (x2) ... (à (xn) corps) ...)) 
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On remarque ici, de façon très inattendue que la transformation de CURRY 
introduit des difficultés pour les P-évaluateurs, en n'y permettant pas 
l'évaluation partielle (BURSTALL 1971, STOY 1974, BECKMAN 1976) dont 


voici un exemple. 


Soit à construire une fonction CURRY, de fonctionalité 
(NxN > N) > N> (N> N)) 
sa définition sera 


(DE CURRY CS) 
(LAMBDA CX) CLAMBDA CY) CS X Y)))) 


dont l'évaluation partielle donnera, avec 


CSETQ ADD CCURRY +)) 


et 


CSETQ ADD3 (ADD 3)) 
CADD3 4) > 7 


L'exclusion de ce mécanisme d'évaluation partielle dans les P-évaluateurs y 


interdit l'usage direct des STREAMS. 


Toutes ces difficultés nous aménent à introduire un troisième évaluateur 


qui nous permettra 


1) d'obtenir les mêmes résultats que ceux livrés par N-EVAL 
2) d'éliminer les problèmes de FUNARG 
3) de permettre la programmation par passage de continuations, 


et l'usage des STREAMS. 
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3.7.7 F-EVAL : UN LAMBDA-INTERPRETE A FERMETURES 


Les difficultés liées aux P-évaluateurs résidaient essentiellement dans 
les pertes de liaison (FUNARGs ascendants) et dans les liaisons parasites 
(FUNARGs descendants) introduites dans l'environnement. 

La solution à ces problèmes réside dans un mécanisme de protection 
des liaisons, assez semblable au mécanisme de protection que nous avons vu 
à l'oeuvre dans les différentes versions de l'opérateur point-fixe. 
Toutefois, l'objet à protéger n'est pas ici une expression, mais un environnement. 
La solution à ce problème d'écologie va consister à fermer une lambda-expression 
comportant des variables libres avec son environnement actif au moment de son 
évaluation : l'évaluation d'une lambda-expression donnera une telle association 
sous le nom de fermeture. Lorsque le corps de cette lambda-expression sera évalué, 
par suite de son application, ses variables libres seront alors évaluées dans 


cet environnement fermé. 


Ce mécanisme sera implémenté grâce à une nouvelle structure de donnée, 


les fermetures que nous noterons 
(B une-}-expresston un-environnement ) 


La création d'une fermeture n'aura naturellement pas lieu par recopie, mais 


par l'allocation d'une paire de pointeurs. 


Il nous faut encore étendre le domaine des expressions évaluables par notre 
troisiéme interpréte F-EVAL, par la classe des fermetures que nous noterons 
FER. L'interpréte F-EVAL est essentiellement équivalent aux interprétes 
SCHEME (SUSSMAN 1975), DARWIN (STEIGER 1976), PLASMA (SHROBE 1976) et 


MICRO-PLASMA que nous examinerons au chapitre 5. 
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F-EVAL (x , ENV] = 


1. gt XEN U {t , nil} U OPRIM alors x 
2 st x € VAR alors VALEUR [x , ENV] 
34 st x € LAMBDA alors (B x ENV) 


4. st x € APPL avec x= (fe) ou x = (f el e2) 


Sy st f © {Et , nil} alors F -EVAL [el , ENV] 
| OU F -EVAL Ce2 ; ENV] 


selon f 


6. st f € OPRIM alors £ [F-EVAL [e , ENVI] 
ou f (F-EVAL Cer , ENVI , F~EVAL fez , EWII 


A st £ € FER avee f= (B Q (v) corps) ENV’) 


alors 


F~EVAL [corps , Lier Cv , F-EVAL fe , ENV] , ENV“ IJ 


8. st f£ € APPL VY VAR YV LAMBDA alors 
F-EVAL c(F-EVAL [£ , ENVI e) , ENV] 
sinon erreur 


stnon erreur 


61 


F-EVAL réalisant, de même que P-EVAL l'appel par valeur, le traitement de 
la récursion y sera identique, sauf dans le cas où la récursion dépend 
du traitement correct d'un FUNARG : F-EVAL est alors gagnant, comme l'indique 


l'exemple suivant. 


La construction des fermetures y sera représentée par des squelettes 


de type 


(B Le-code L'environnement) 


/ 


Reprenons notre exemple de la fonction CURRY, introduite au §3.6.2 


CURRY = CA CE) CA OO: CA CY) (CF X V2) 


Nous obtiendrons sous F-EVAL les évaluations partielles 


(CURRY +) > (B Le-code L'environnement) 
O00 (A WY) (FX VOD ee, + a 
et 
CCCURRY +) 3) > (B Le-code L'environnement) 
he. 
(A (Y) (F X Y)) E CX y Duce 
et enfin 


CCCCURRY +) 3) 4) > F-EVAL [CF X Y) , L'environnement] 
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3.8.- CONTINUATIONS DANS LES l'-EVALUATEURS 


Une continuation est la spécification explicite du prochain calcul à 
effectuer après l'achèvement du calcul courant. Cette notion, que nous avons 
déjà rencontrée à plusieurs reprises a été dégagée nettement par (FISCHER 
1972) dans le cadre d'une stratégie d'implémentation d'environnements selon 
une discipline de pile, par Strachey et Wadsworth (STRACHEY 1974) pour 
donner une sémantique mathématique de la notion de branchement, par 
(REYNOLDS 1972) pour éliminer des interprètes définitionnels le problème de 


leur dépendance ā l'égard de l'ordre d'application, en particulier dans le 


cas de l'appel par valeur. 


Ce concept essentiellement théorique a reçu récemment plusieurs appli- 
cations pratiques, en particulier pour distinguer les appels récursifs des 
appels itératifs en PLASMA (HEWITT 1977), pour obtenir dans les compilateurs 
un traitement uniforme des noms et des valeurs intermédiaires (STEELE 1976b), 
enfin pour l'implémentation de structures de contrôle non récursives comme le 
saut généralisé dans le cadre de l'appel par valeur. En effet si l'appel par 
nom permet d'ignorer un argument, le passage de cantinuations permet d'ignorer 


une continuation. 


Nous utilisons très largement le concept de continuation dans notre 
méthode de spécification d'implémentation par filtrage (et: 4:30). 
Pour introduire à la notion dans le cadre de LISP, nous procéderons 


largement au moyen d'exemples. 


La programmation par passage de continuations vise, dans les lambda-interprètes 


à un double but 


1) lever l'opacité textuelle inhérente tant aux langages de 
type LISP qu'aux interpretes d'expressions applicatives 


en général. En effet, dans un appel de fonction, l'appelé 


(1) stratégie d'élimination, par opposition à une stratégie de rétention, 
a“ ` t i A 
apparentée à la fermeture d'environnements dans les F-evaluateurs. 


2) 


est clairement spécifié mais le destinataire de la valeur 
retournée par cet appel n'est pas spécifié. La compréhension 
de la désignation exacte du destinataire (ou receveur) de 
cette valeur (ou message), repose, de la part du programmeur, 
sur Sa connaissance du mécanisme de l'interprète. Si nous 
voulons construire des systèmes d'aide à la mise au point 
très efficients, la spécification exacte du destinataire de 


la valeur retournée est une information indispensable. 


certaines applications font clairement appel à un traitement 
de style ptpe-line, par étapes séquentielles. Lorsqu'un 
carrefour de suites de calculs se présente, nous voulons que 
le choix d'une de ces suites soit définitivement exclusif des 
autres. Or le mécanisme récursif des lambda-interprètes 
réalisant l'appel par valeur est équivalent 4 un balayage 


d'arborescence descendant et préfixe. 


exemple : 


Si, à chaque sommet de l'arbre, un environnement est construit 
9 3 


à l'aller, cet environnement disparaît au retour. L'environnement 


de al sera devenu inaccessible lorsque l'appel a2 sera 


évalué. Des nécessités d'exécution surveillée en mise au point, 


nous aménent à souhaiter obtenir un déroulement de calcul 


tel que 


al 


a2 
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dans lequel toutes les liaisons demeurent accessibles, aucun 
environnement n'étant détruit par garbage collection, faute 


d'accessibilité à partir d'une fermeture. 


Le style de programmation par passage de continuations, present a tous 
les niveaux d'implémentation de PLASMA, est, dans les interprètes a fermeture 
tels que F-EVAL ou SCHEME une tentative de rendre explicite le destinataire de 
toute valeur calculée, et de conserver accessibles tous les environnements qul 
auront été construits au cours du calcul. 

En voici le principe : soit g une fonction qui retourne un résultat à l'appe- 
lant. Le passage de continuation consiste à transformer g de telle sorte que 


l'appelant est passé à g comme argument fonctionnel additionnel. 


L'expression 
Cappelant CF (G CH argument)))) 
sera ainsi transforme en 


CH argument (LAMBDA (X) CG X CLAMBDA CY) CF Y appelant))))) 


Exemple I 


Voici la transformée de la fonction factorielle, avec l'argument 
supplémentaire C = la-continuatton 
(DE FAC CN C) 

CIF C= N 0) CC 1) 

CFAC C- N 1) 
(LAMBDA (X) CC Cx X N)2))))) 

Cette fonction ne ramène aucune valeur, mais passe le résultat 
calculé à un destinataire explictte : la-conttnuatton C. 


L'effet ordinaire de FAC sera obtenu par l'appel 
(FAC N CLAMBDA CX) X)) 


dans lequel le destinataire explicite est la fonction identité. 


Le carré de factorielle sera obtenu par l'appel 


(FAC N CLAMBDA CX) CX X X))) 
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On voit ici clairement la nécessité d'un mécanisme de fermeture 
pour obtenir les valeurs correctes des variables libres N et C 


dans 

(LAMBDA (X) Cc Cx X N))) 
qui est le destinataire de 
CRAG C- N 1)... ) 


Exemple_2 : 
La transformée de la fonction Fibonacci sera 
(DE FIB CN C) 
CIF (<N 2) CC N) 
CFIB C- N 1) 
(LAMBDA (X) CFIB C- N 2) 
(LAMBDA CY) CC G+ X Y)))2))))) 


La nature séquentielle du calcul obtenu est ici trés nette, 


ainsi que la conservation des environnements 


el = (FIB C NI)... ) dans ENVI 
e2 = (FIB C- N 2) dans ENV2 

| avec < X , F-valeur-de-el > 
e3 = (+ X YD dans ENV 3 


| avec < Y , F-valeur-de-e2 > 
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La transformée de la fonction d'Ackermann 


(DE ACK (X Y C) CCOND 
CC= X 0) CC (+ 1 vD) 
CC= Y 0) CACK C- X 1) Y C)) 
3 eae —— CT CACK X C- Y 1) 
(LAMBDA (Z) CACK C- X 1) Z C)))))) 


La séquentialité induite par la clause 3 


el = (ACK X C- Y 1)... ) dans ENVI 
A 

v 
22 = (ACK C= X P wss) dans ENV2 


avec < Z , F-valeur-de-el > 


n'est post-récursive, done itérative, qu'en apparence. La préservation 


des environnements précédents, par inclusion, est une garantie de non- 


itération. 


De façon indépendante des questions de mise au point, certaines applications 
conduisent naturellement au passage de continuations. En voici, dans l'esprit de 


LOGO (PAPERT 1973), un exemple très élémentaire. 


Donnons nous une version idéalisée d'un mobile de Calder de masse 


globale n. 
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Il sera représenté par la structure 


mobile ::= n | (mobile mobile ) 
n/, ny, 


construisons une fonction MOBOK qui, argumentée d'une telle 
structure, vérifie s'il s'agit ou non d'un mobile légal et 


équilibré. Une première solution serait 


CDE MOBOK (M) 
CIF CATOM M) M 

CCLAMBDA (X Y) CCOND 
CCNULL X) NIL) 
CCNULL Y) NIL) 
CC XY) C+ X Y)) 
CT NIL))) 

CMOBOK CCAR M)) CMOBOK CCADR M))))) 


Cette solution est trés inefficiente si le sous-mobile CCAR M) 
n'est pas équilibré : dans ce cas, au lieu de stopper immédiatement 
le calcul en ramenant NIL, le sous-mobile CCADR M) est testé 


inutilement. 


Une solution plus efficiente sera la transformée de MOBOK par 


passage de continuation. Deux continuations seront passées 


1) une continuation CFAUX permettant d'échapper 
à la suite du calcul, et simulant avec un F-évaluateur 


le mécanisme de ESCAPE de VLISP (cf. §6.2.9) 


2) une continuation CVRAI qui spécifie le destinataire 
d'un calcul jusqu'ici satisfaisant et pouvant donc 


etre continué 
La transformée sera : 


CDE MOBOK (M CFAUX CVRAI) 
CIF CATOM M) CCVRAI M) 
CMOBOK CCAR M) 
CFAUX 
(LAMBDA (X) 
CMOBOK CCADR M) 
CVRAI 
CLAMBDA CY) 
(IF (= X Y) CCVRAI (+ X YD 
CCFAUX)))))))) 
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L'appel initial sera 
CMOBOK le-mob7ile (LAMBDA ©) NIL) CLAMBDA (X) X)) 


Ainsi MOBOK ne retourne aucune valeur, mais passe un message 

à un receveur. On notera que CFAUX, la continuation d'échappement, 
permettrait de passer une information indiquant pourquot la suite 
du calcul n'a pas eu lieu, voire cette suite de calcul elle-même, 


s'il s'avérait que sa reprise puisse être effectuée. 


Ces indications avaient pour but de familiariser le lecteur avec la 
notion de continuation dans le cadre de LISP, à travers ses applications. 
Nous renvoyons à (MILNE 1976) et (RUSSEL 1977) pour les développements 
théoriques récents qui en sont issus. Nous l'utiliserons très largement, 
en particulier au chapitre 5, pour décrire l'implémentation de MICRO-PLASMA, 
a l'aide de la méthode des filtres que nous allons examiner au cours du 


chapitre suivant, 
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CHAPITRE 4 


IMPLEMENTATION DE LISP : 
SPECIFICATION PAR LA METHODE DES FILTRES 


4.1.1.- ASPECTS ACTUEL 


Une des caractéristiques principales du langage LISP est la circularité 
de la définition de ses interprétes. Toutefois les interprétes publiés du LISP 
pur, ainsi décrits en LISP pur ont l'inconvénient de ne pas donner d'indications 
précises sur le mode d'implémentation de LISP dans un langage de plus bas enr 
et de ne pas reflèter l'évolution du langage, tel qu'il est effectivement utilisé 


dans les études d'Intelligence Artificielle. 


Cette évolution s'est traduite par l'extension de la définition de nombreuses 
fonctions LISP importantes et par le souci d'efficience de l'implémentation en 
ce qui concerne l'accès aux variables. Un trait principal des systèmes LISP 
contemporains est l'abandon de la A-liste, et la généralisation de l'accès 
rapide aux variables, à une indirection près, par liaison superficielle 


(2) ee 


. Les interprètes LISP sont à présent essentiellement des 


(shallow binding) 


P-évaluateurs (cf. §3.4). La conséquence immédiate de cette décision est l'abandon 


(1) à l'exception de l'implémentation sur PDP 1 d'une version extrêmement 
réduite de LISP 1.5 (DEUTSCH 1964) 


(2) l'environnement est implémenté comme un environnement global, où toutes 
les variables sont a priori accessibles en écriture par SETQ et SET, et 
en lecture aprés initialisation. Ainsi les primitives CSETQ et CSET de 
LISP 1.5 ont totalement disparu. 


a GN re rr Po PP mr Pr mr a E ATI 
a ee a a RS RS TR eS DE NT ED: 


des objets FUNARG de LISP 1.5 et de l'expression LABEL. De toutes manières, 
malgré leur grand intérêt théorique (NEWEY 1975, GORDON 1973, 19/75a,b) ces 
constructions en LISP 1.5 demeuraient très limitées eut égard aux besoins 
actuels : les objets FUNARG ne donnent pas accès à la structure de contrôle, 
i.e. ne comprennent pas de continuation, enfin les formes LABEL ne permettent 


pas la définition simultanée de procédures récursives. 


Ainsi les principaux systèmes LISP actuels : MACLISP (WHITE 1970, MOON 1974, 
LAUBSCH 1976), INTERLISP (TEITELMAN 1974, HARALDSON 1975), et LISP 1.6 

(QUAM 1973), se révèlent très différents, tant dans leur usage que dans leur 
définition, du LISP pur originel, aussi bien que du LISP 1.5 de 1962. Ces 
systémes nécessitent pour leur implémentation des configurations trés importantes 


qui en interdisent pratiquement la transposition sur mini-ordinateurs. 


4.1.2.- LISP SUR MINI-ORDINATEURS : INTERPRETATION VS COMPILATION 


aam am mm m ei ne eur vei ee ee ee ed i ee ee ee ee ee ee ei ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee eee 


L'implémentation de LISP sur mini-ordinateurs pose alors le probleme 


de trouver un compromis acceptable entre 


(1) la puissance du systéme : la plupart des utilisations de LISP, 
hautement expérimentales, nécessitent des modifications extré- 
mement fréquentes des programmes interprétés. Certaines parties 
pourront demeurer relativement stables et seront naturellement 
compilées. Reste que la stabilité d'un ensemble de fonctions 
n'étant pas prévisible à l'avance, exige de l'utilisateur 
d'employer LISP avec de nombreuses précautions restrictives. 
Ces restrictions de langage, en particulier l'emploi massif de 
fonctions de type PROG (LUX 1975) ont pour conséquence un 
extrême encombrement de la mémoire disponible (LISP 1.6 n'autorise 
pratiquement que ce style de programmation, de « type-FORTRAN »). 
La compilation des fonctions LISP, est malgré son élégance 
apparente, un processus très lourd. De surcroît, il se révèle 


que sur mini-ordinateurs, les fonctions compilées sont d'un 
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encombrement équivalent, sinon supérieur 4 celui des fonctions 
interprétées, et nécessitent de toutes manières de fréquents 
appels à l'interprète. La situation est exactement inverse dans 
les systèmes LISP implémentés sur des configurations importantes. 
Ainsi le très grand nombre de fonctions de faible puissance 
faciles à compiler des grands systèmes LISP, devra être remplacé 


sur mini-ordinateur par un petit nombre de fonctions puissantes. 


(2) les possibilités d'utilisation effective : les systèmes LISP 
pour mini-ordinateurs doivent comprendre des fonctions interprétées 
très puissantes. Fonctions de contrôle : expressions conditionnelles 
étendues, sélection par cas, fonctions de sortie avec restitutions 
instantanées de contextes, itérations structurées ; fonctions de 
données : filtrage de listes par position ainsi que filtrage par 
contenu. Ces fonctions permettent ainsi une implémentation aisée 
et compacte des extensions actuelles de LISP, en particulier de 
type PLANNER (SUSSMAN 1971, HEWITT 1972) et CONNIVER (McDERMOTT 
1974), extensions qui sont devenues 4 présent indispensables 


aux études d'Intelligence Artificielle. 


Nous nous proposons de décrire le noyau d'un systéme LISP : VLISP, pour mini- 
ordinateurs qui réalise ce compromis. Il est clair que nous ne proposons ni 

un systéme portable (NORDSTROM 1971, BERTHOD 1976), ni une standardisation 

de LISP telle que celle de HEARN (1969), qui de toutes fagons ne serait 

nullement nécessaire. Tout au contraire, nous décrirons en détail l'implémentation 
du système VLISP, reflétant l'état du langage tel qu'il est, à l'heure actuelle, 


effectivement utilisé. 


Cette description sera donnée sous forme de programmes dans une notation elle- 
même issue des plus récents développements de LISP en fonctions de données 


la notation par ftltrage. 


4.1.3.- PROBLEMES DE DESCRIPTION 


té p uv Sw wi opaa ee ee ee må 


Cette notation nous permettra de décrire la syntaxe concréte des objets 
LISP créés et manipulés par l'interprete. 
En effet, la traduction préalable de programmes LISP en termes d'une syntaxe 
abstraite est peu appropriée : la syntaxe externe de LISP est isomorphe aux 
représentations internes de programmes sous forme de listes. La décomposition 
accompagnée d'un marquage de ces éléments, est inutile en LISP : cette 
catégorisation est déjà inhérente au langage externe. Y contribue naturellement 


l'absence de séparateurs et le parenthésage total des expressions du langage. 


De surcroît l'emploi d'une syntaxe abstraite vise à rendre la description 
indépendante d'une notation particulière. Nous nous écartons résolument de ce 
point de vue dans le cas de LISP et de ses dérivés. Tout au contraire, nous 
maintenons que l'implémentation de LISP nécessite une notation très adaptée 


au langage externe et à sa représentation interne. 


Une notation est importante pour ce qu'elle laisse de côté. Les programmes 
LISP étant des structures de données, nous avons besoin d'une notation qui 
décrive directement, et de façon très expressive les effets des opérations 
appliquées à ces structures, et non pas indirectement en termes de relations 


ou d'équations. 


La notation que nous proposons vise à untfter les descriptions de structures 
de données, et d'opérations définies sur ces structures. Pour spécifier 
l'implémentation de LISP, données et opérations doivent être vistbles. Si 
représenter, c'est rendre sensible, nous pensons que le pouvoir expressif 
d'un langage de description est conditionné par l'ensemble des opérations 


abstraites directement représentables dans ce langage. 


C'est ce que nous proposons avec la notation par filtrage, un filtre étant 
à mi-chemin d'une description intensionnelle (procédure) et extensionnelle 


des données. 
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Cette notation nous permettra de décrire la syntaxe concréte des objets LISP 


créés et manipulés par l'interpréte, tout en nous permettant 


(1) d'éviter de faire dépendre la description de l'interprète 


des caractéristiques d'adressage d'ordinateurs particuliers 


(2) de ne pas accéder aux composantes de LISP par des chaînes 
opaques et fastidieuses de sélecteurs CAR et CDR : notre notation 
nous permet la référence immédiate à des composantes en position 


1) 


quelconque 


(3) de ne pas engager prématurément des décisions d'implémentation 
de trop bas niveau, en particulier en ce qui concerne l'accès 
aux variables, et le mode d'implémentation de la zone de contrôle 


de l'interprète. 


Cette notation permet de surcroît de rassembler les notions d'affectations, 
de tests, de spécification de structure d'expressions symboliques LISP, d'accès 


ā des composantes arbitraires de listes, dans une description unifiée. 


Avant les descriptions de l'implémentation du systëme VLISP qui seront données 
au chapitre 6, nous exposerons notre notation de filtrage, puis nous décrirons 
les structures de données VLISP et leur organisation en mémoire, ainsi que la 
spécification en terme de filtrage de nos structures de contrôle sous forme de 


continuations. 


(1) notre notation a donc une puissance descriptive très supérieure à celle 
proposée par (KOWALSKI 1973), cette dernière ne permettant pas les 
A a . AL A A . ` a . 
references directes a des elements en position arbitraire. 
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4.2.- L'OUTIL DE NOTATION : LE PILTRAGE'”” 


Le filtrage est une expression booléenne que nous noterons 
Ait F 


dans laquelle l'argument A est une S-expression quelconque et F est un feltre: 
Le filtre F est de même une S-expression pouvant également comporter des 
variables LISP spécialement distinguées que nous nommerons variables de 


filtre. 


Soit Vos es Vn les variables de filtre ayant des occurences dans F. 
Le probléme du filtrage est de trouver une SULEG S y cesy S de S-expressions 


telles que 
Cy, en Le Soe s) = A 


l'évaluation d'un filtrage est un processus séquentiel et déterministe qui 
consiste à substituer aux variables de F des éléments constants de À en 

même position, que nous dirons ftitrés dans À, de telle façon que F devienne 
identique à A. Si cela est possible, nous dirons que le filtrage est satisfait, 


et dans le cas contraire, qu'il échoue. 


(13 Formellement notre filtrage est une version déterministe de la semti- 
unification. (HUET 1975, 1976) donne un exposé détaillé des problémes 
formels d'unification et de filtrage, ainsi que de nombreuses 
applications 
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Exemple 

si A = ((1) (2 c d C1)) 2 c d) 
et F= (ix (?y d !x) ?y d) 

(où x et y seront les variables du filtre F, le préfixe (!) spécifiant 

comme variable d'élément, et (?) spécifiant y comme variable de segment) 
alors A :: F est satisfait pour la substitution x = (1), y = € 
si encore A= (1 Cd 1) d) 
alors A :: F est satisfait pour la substitution x = 1, y = NIL 
mais si A= (1 (a 1) 1 d) 
alors il n'existe aucune substitution qui satisfasse A :: F, échec ici 


du filtrage. 


Les variables du filtre seront localement liées (sur un environnement séparé, 
dont l'existence est limitée au temps du filtrage) a ces éléments constants 
de A que nous nommerons F-valeurs des variables locales du filtre (en les 
distinguant des valeurs normales des variables LISP que nous nommerons 
C-valeurs}). En cas de succès du filtrage, la F-valeur des variables du filtre 
devient la C-valeur des variables LISP correspondantes ( par délocalisation 
des variables du filtre). En cas d'échec, la C-valeur des variables du filtre 


f1) 


n'est pas modifiée. 


SPECIFICATION DES FILTRES 


Soit k un atome LISP constant, v une variable, s un segment de A, f 
un filtre, e une expression LISP évaluable. Les caractéres préfixes (cf. 
§6.2.5.2) (!), (2?) et (,) ont pour rôle de repérer syntaxiquement le type des 


variables. 


(1) le filtrage ici décrit est une fonction standard de VLISP (cf. 86.2.13). 


X 


2 c) 


Un filtre f pourra être constitué par 


(1) k un atome LISP. k doit être identique a A. 


TS 

H. 

Ha 

Ver 
| 


une variable d'élément anonyme : elle filtre A sans 


contrainte. 


(12 


une variable d'élémént nommée : elle filtre A sans 


Pom 
fos 
poe 
p. 

LA 
< 


contrainte et v se trouve localement liée a A. 


(iv) ?- une variable de segment anonyme : elle filtre un 
segment s le plus court possible de A , de 0 


éléments ou plus. 


(1) 


(v) ?v une variable de segment nommée : elle filtre un 
segment s le plus court possible de À , et 


se trouve localement liée à s.. 


(vi) Pa la F-valeur locale de la variable v , si cette 


liaison locale existe, sinon la C-valeur de v. 


(vii) Pe. aa 6) identique à (iii). Toutefois les e, ... e, sont 


des expressions LISP qui imposent des contraintes 
à la F-valeur de v . Les e ... e, sont évaluées 
en séquence, et aucune d'entre elles ne doit 


s'évaluer a NIL. 
(Gini) “Cy, waa tes 2 identique à (vii) pour les variables de segments. 


(ix) {KALT* f... f ) une suite de filtres f, ... f telle que si Ar: f 


alors succès sinon si A :: ES alors succès sinon 


Mee "Si. À 28 E alors succès sinon échec. 


(x) Ch. i ate Tao une suite f, ... f de filtres tels que chacun 


d'eux doit filtrer un élément ou un segment de A 


en méme position. 


(1) naturellement, si v , ayant déjà €L rencontrée dans le filtre, possède 
une F-valeur, !v et ?v représentent alors la F-valeur de la variable 
v 


i i ee ER sage ae a een eS RE RSR angen ee 


En cas d'échec d'un filtre f, , i>l , une nouvelle tentative est effectuée 

avec un filtre de segment fj , i>j , par adjonction d'un élément supplémen- 
taire de A au segment filtré par f; , 
des filtres fia fja ++. fin fi sont annulées. 


et les liaisons locales des variables 


Le filtrage échoue totalement s'il y a échec d'un filtre f,,, et qu'il 


n'existe pas de filtre de segment fie; + 


Nous utiliserons également les abréviations suivantes 
t — 
x ie CQUOTE x) 
(x : y) = € CCONS x y) 


CR HR ede RE. ON) = a6 CCONS +x: (CONS: wae: CCONS x. FJ sa 2) 


es te CRD et toe 


Si L est une liste non vide 


L :: (?- IA1) peut être décrit comme 


CSETQ Al CLAST L)) 


CKY NIAL comme 
CSETQ L CCONS X CCONS Y L))) 


L 32 C?= €,Al : !A2) ?-) comme 


CAND CSETQ X CASSOC Al L)) 
CSETQ A2 CCDR X))) 


L FE COTAT PAD) BED comme 


(COND CCLISTP CCAR L)) 
CSETQ Al CCAAR L)) 
CSETQ A2 CCDAR L)) 
CSETQ L CCDR 1b) 


L i: €?- X ?-) comme 


(MEMQ 'X L) 


a 


(?A1 AL) 
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filtrant un argument de type (segment même-segment) 
et affectant si c'est le cas le segment de liste à 


Al peut être décrit comme 


(COND 
CL CAND 
CEVENP CLENGTH L)) 
CEQUAL CSETQ Y 
CNTH CSETQ X CADDI CQUO CLENGHT L) 2))) 
L)) 
(REVERSE CNTH X CREVERSE L)))) 
CSETQ Al Y))) 
CCSETQ Al NIL))) 


dont l'inefficience laisse réveur. Ou encore par (cf. § 6.2.10) 


(LET CCL L) CY NIL) CCOND 
CCEQUAL L CREVERSE Y)) CSETQ Al L)) 
CCNULL L) NIL) 
CT CSELF CCDR L) CCONS CCAR L) Y))))) 
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4.3.- FILTRE : UN LANGAGE DE DESCRIPTION D' IMPLEMENTATIONS 


4.3.1.— LES OBJETS DECRITS : ATOMES, LISTE DE CONTROLE, CONTINUATIONS 


a A ee eal eh A mé a A a i a PA mh D e= ge Ve a ee ee oe ee ee ee ee oe 


4.3.1.1.- Atomes 


Bien qu'un atome LISP soit en principe un objet indécomposable par 
des moyens chimiques (CAR et CDR), il convient, s'il s'agit de décrire 


son implémentation, de lui imposer une certaine structure. 


Nous distinguerons deux types d'atomes 


. les nombres : un nombre n sera représenté par une 


S-expression (nombre : n) 


. les atomes non-numértques : un tel atome x sera 


représenté par la donnée de quatre champs 
<x.CVAL, x.PLIST, x.CODE, x.NOM> 
tels que 


x.CVAL : valeur LISP de l'atome x 
considéré comme variable 

x.PLIST : P-liste de l'atome x 

x.CODE : continuation associée ä x dans 
l'interprète si x est une fonction 
standard 


X. NOM : nom imprimable de l'atome x 


Les atomes de ce type peuvent être testés par égalité, mals ne sont pas 


ordonnés entre eux et ne peuvent pas être objets d'opérations arithmétiques. 


4.3.1.2.- Liste de contrôle 


Il s'agit d'une liste quelconque, pouvant donc être argument d'un 


filtrage. Elle pourra comprendre 


. des atomes 
. des listes LISP 


. des continuations de l'interprète. 


Elle sera le plus souvent gérée comme une pile. L'organisation interne de 
cette pile dépend naturellement du langage implémenté. Une description 


détaillée dans le cas de VLISP sera donnée au $6.1.4. 


4,3.1.3.- Continuations 


Une continuation c est une suite ordonnée de filtrages 


Nous distinguerons des continuations nommées, par exemple 
EVAL = c 


et des continuations anonymes, par exemple 
alors c 


sinon c 


(1) Comme nous l'avons vu au $3.8, la technique des continuations cons 
ajouter à une fonction f(x,,...,x,) un argument fonctionnel supp 
y , la continuation, et à transformer f en une nouvelle foneti 


FE ETE ey = FICER yesss Ka)? 


telle que f' ne retourne pas une valeur, mais retourne une combinaison 
qui est l'application de la continuation y À la valeur calculés par f. 
Notre interprétation des continuations est fondée sur la possibilité de 
défonctionaliser une continuation en une liste finie d'instructions 


(REYNOLDS 1972). 
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Nous utiliserons pour décrire l'interpréte VLISP deux variables de continuation 
C qui désigne la continuation présente et R qui désigne une continuation de 
retour. Nous nommerons filtrage actif le premier élément de la continuation 


presente. 


Nous utiliserons les structures de contrôle suivantes : 
soit Cl et C2 des continuations et P une liste de contrôle 
. (C(c2 : P) cl) :: C!P IC) abrégé en rec cl ; c2 


qui est interprété naturellement comme un appel récursif, la 
continuation c2 est empilée dans la liste de contrôle, cl 
devient la continuation présente et son premier élément devient 


le filtrage actif. 
* Ps: (IC ?P) abrégé en derec 
retour tape récursif. 
e Cel c2) :: (IC !R) abrégé en app cl 3 c2 


qui est interprété naturellement comme un appel non nécessai- 


rement récursif, et non nécessairement suivi de retour. 


$ R :: !C abrégé en ret 


A tout filtrage sera associée une continuation exceptionnelle qui deviendra 
la continuation présente en cas d'échec du filtrage. 


Nous distinguons ainsi les expressions condtttonnelles 


st À :: F alors cl fst c2 


et st A :: F alors cl sinon c2 fst 


dans lesquelles la continuation exceptionnelle est c2 , 


et les expressions tneondtttonnelles 
Sea, se Ss 


dans lesquelles la continuation exceptionnelle est dépendante d'une implémen- 
tation particulière, l'interprétation usuelle étant la communication à 
l'utilisateur du système VLISP d'un diagnostic d'erreur, suivie d'une activation 


de la boucle-racine-LISP (cf. §6.2.1). 
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Par commodité, nous utiliserons également des abréviations telles que 


tantque £ fatre c ftan 


pour E = st f alors c ; app E fst 


Le filtrage permet également l'expression d'appels de coroutines. 
Soit PX et PY respectivement listesde contrôle des continuations X et 
Y , et cq des continuations quelconques. 


Les appels de resume dans 


cq 3 resume Y 5 cx 


et Y= cq ; resume X 3 cy 
seront des abréviations de 
(PY cx : PX) :: (C!C ?PY) ?PX) 


et CPX er SPY ee CCIC Px) Ory) 


A ce propos, on notera qu'un filtrage peut être décomposé en filtrages 


successifs plus élémentaires 

(E E : P) :: CCE ?-) ?P) 
est décomposable en restant équivalent à 

CE: P) :: IP; E :: (IE ?-) 
mais n'est naturellement pas équivalent a 


Ih CIE 22) oi CE FD re TP 


Les optimisations habituelles d'appels récursifs restent valides en FILTRE 


. si X s'achève par derece alors 
rec X ; derece 


est optimisable en 
app X 


. si X et Y s'achèvent toutes deux par derece alors 
Yee X 3 app r 
est optimisable en 
CY A, PI ae eS pp R 
. pour répéter deux fois le tronçon final cx de 
cx ; derec 
on pourra écrire 


ree cx 3} cx 3 derec 
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4.3.2.- UN EXEMPLE DE TRADUCTION FILTRE VERS LANGAGE-MACHINE 


Tur eur ver ier cr 2 MU pete mg mule fl mms FF ue je ee UN cer cr GE GUN GE cats Gaule mule om den Es des eee eue dt ONU AN ee es ee ee mme gum ee 


Nous allons a présent illustrer le processus de traduction d'une fonction 
LISP à son implémentation dans un langage de très bas niveau. L'implémentation 
sera la résultante du passage de la version récursive à la version itérative 
en FILTRE. 
Cette version itérative pourra alors être codée dans le langage assembleur 
d'un ordinateur existant en tenant compte de ses limitations propres. 


La traduction consistera à 
1) transformer les variables locales en variables globales 


2) exprimer les appels récursifs en FILTRE par rec et les 
retours (laissés implicites en LISP) d'appels récursifs 
par derec. 
Dans la traduction ultime en assembleur, on pourra exploiter 
la possibilité offerte par certaines machines de branchement 


avec rangement en pile de l'adresse suivant le branchement 


BSR pour l'ordinateur T1600 
PUSHJ reg-pointeur-de-pile pour l'ordinateur PDP 10 


ainsi que la possibilité de branchement à l'adresse en sommet 


de pile avec dépilage 


exemple 
RSR en T1600 
POPU reg-potnteur-de-ptle EN PDP 10 


lorsque l'ordinateur ne permettra pas ces facilités (ex 
IBM 370, CII 10070, IRIS 80, MITRA 125, NOVA 1200), il 
conviendra de s'écrire des macros capables de les réaliser de 


façon efficiente. 


= a a oe —_ — 


en Metasymbol 10070 (CII 1970) rec et derec pourront être 
définies comme les macros suivantes, le registre 8 


servant de registre de liaison : 


REC CNAME 
PROC 
LI,8 S$+3 
PSW,8 PILE 
B AFC1) 
PEND 


DEREC CNAME 


PROC 
PLW,8 PILE 
B “8 
PEND 
3) traduire en FILTRE les appels non-récursifs par app, et 


ret en cas de retour. En assembleur, un app non suivi de 


retour sera traduit naturellement par un branchement 


4) définir les fonctions primitives comme des sections de 


code définies par leur point d'entrée (ex : CONS) 


5) établir des conventions de passage d'arguments. On 
conviendra dans ce qui suit que les arguments des fonctions 
seront passés dans les registres Al, A2, A3, etc., la valeur 


retournée par la fonction étant passée dans Al. 


(1) 
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Soit la fonction PROGN exprimée en VLISP (cf. §6.2.1) 


(DE PROGN CL) 
CIF CNULL CCDR L)) CEVAL CCAR L)) 
CEVAL CCAR L)) 
CPROGN CCDR L)))) 


Voici l'implémentation en FILTRE du module PROGN de VLISP 


PROGN = 
tantque (Al Al : P) :: CCIAl !- ?-) ?P) fatre 
rec EVAL; P :: CC!- ?A1) ?P) 
ftan 
Al :: CIAL); app EVAL 


Elle sera, en assembleur ASM T1600 (TELEMECANIQUE 1974) traduite sous 


la forme 

PROGN: LA Al 
JMP TEST 

LOOP: PSR A 
BSR EVAL 
PLR A 

TEST: LR A,L 
LA CDR, L 
CP ADNIL 
LB CAR,L 
STB Al 
JNE LOOP 
BR EVAL 


Al est en mémoire. Le registre de base L est utilisé comme index. Le 
registre A est utilisé pour les comparaisons. les cars et cdrs sont deux mots 


de 16 bits consécutifs, d'accès par déplacements respectifs de 0 (CAR) et 1 (CDR) 


PROGN sera, en assembleur MACRO PDP 10 (DEC 1974) traduite sous la forme 


LOOP: PUSH P,A2 
PUSHJ P,EVAL 
POP P,Al 

PROGN: HRRZ  A2,CA1) 
HLRZ Al, CAL) 
JUMPN A2, LOOP 
JRST EVAL 


Al et A2 sont des registres en mémoire rapide. L'adresse de NIL est 0. Les cars 
et cdrs sont deux demi-mots de 18 bits accessibles en lecture par HLRZ (CAR) et 


HRRZ (CDR). 


Lorsque la machine n'a pas de registre d'index (comme par att l'ordinateur DEC 
PDP 8), il convient de privilégier l'accès aux CARS plutôt qu'aux CDRS. La lecture 
du CAR est l'action de très loin la plus fréquente effectuée par un interpréte LISP: 
Jusqu' à 11% de l'ensemble des actions. Ce phénomène a été observé sur VLISP PDP 10 
grâce à l'utilitaire de comptage par type, d'instructions exécutées, répondant 


au nom pittoresque de SNOOPY-TATTLE. En revanche, nous avons observé que les accès 
af 


PCIe SR EO te ee a a oe ASS ee | 
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4.4.- ALGORITHMES DE FILTRAGE : FILTRER EN FILTRE 


Une définition métacirculaire du filtrage va être donnée en FILTRE. 


Dans l'appendice 3 nous donnons en VLISP la traduction de cette définition. 


En anticipant sur l'organisation de la 
au §6.1, et pour demeurer au plus prés 


l'abréviation 


e SHATOM 
de préférence à une écriture de filtre 
e :: Catome !cval 


pour tester si e est ou non atomique 


FILTRER 


FILTRER = 
O :: !A5: ree FILTRI 
stu Al 23 (a bore 


mémoire de VLISP, qui sera décrite 


de l'implémentation, nous utiliserons 


telle que 


'plist !code !nom) 


(1) 


sinon tantque A5 :: (C!AI ?A2) ?A5) fatre 


A2 :: !'AL.CVAL 


fta 
Toi: lAI 
fst 


derece 


Le module principal FILTRER reçoit dans les registres Al et A2 respectivement 


un filtre et une expression a filtrer. 


Dans le registre A5 sera construit 


l'environnement local au filtrage. Le module FILTRI assurera le filtrage 


proprement dit. 


(1) Le «type» d'un objet LISP est défini par son adresse d'implémentation dans 


la mémoire organisée par segments 


. Chaque segment définit donc un type. Ici, 


le type atome est défini par la borne supérieure HATOM de son segment. 
Un contenu de registre pourra ainsi faire l'objet de tests de types grâce 


à une comparaison d'adresses avec 


# = 
une borne supérieure de segment 


INSTANCIER 


INSTANCIER = 
st Al<HATOM alors 
stnst Al :: C/, !A1) alors 
St A1<HATOM alors 
st A5 :: (?- €,Al ?A2) ?-) alors 
CQUOTE A2) :: !Al 
sinon 
(QUOTE AI.CVAL) :: !AI 
fst 
sinon ree INSTANCIER; app EVAL 
For 
stnon (Al Al : P) :: CC!AI ?-) ?P); 
rec INSTANCIER; P :: C!A2 ?P); 
CA2 Al : P) :: CC!- ?AL) ?P); 
rec INSTANCIER; 
Pee CIA? PPS: CA2 © ALD 22 TAL 
fst 


derece 


Le module INSTANCIER assure le remplacement des filtres de type (,v) par 
la F-valeur locale de v s'il s'agit đ'une variable. S'il s'agit d'une 
expression, celle-ci sera évaluée. Tout caractère précédé de (/) n'est pas 


considéré comme caractére préfixe, mais comme un élément constant de filtre. 
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FILTRI 


Le module FILTRI assure le filtrage proprement dit, et construit dans A5 
l'environnement local au filtrage. Chaque alternant principal du module corres- 


pond à un alternant de la spécification des filtres donnée au $6.2. 


FILTERI = 
St Al :: {8ALT* /!- ,A2} alors T :: !Al 
stnst Al :: C/! !Al ?A3) alors 
st A5 :: (?- €,Al ?A1) ?-) alors app FILTRI 
sinon (CAL : A2) : A5) :: !A5; 
sL A3 :: O) alors T :: !Al 
sinon (A3 A5 : P) :: CIAL ?P); 
rec INSTANCIER; 
CAND : A1) :: !Al; 
ree EVAL; P :: C!AS ?P); 
st Al :: © alors A5 :: Cle 2A5) fst 
fst | 
fst 
stnst Al :: (/?- ?Al) alors 
st Al :: © alors T :: !AI 
sinon jusqua A2 :: ©) fatre 
CAS: AL A7 © PX 55 APS rec FILTRE 
P iz C'A3 !A4 (!- 7A2) ?P); 
st Al :: © alors CA3 Al) :: CIAS5 IAL) 
stnon derec 
fst 
fjusq 
Or SAL 
Tee 


sinst Al :: C/, !Al) alors 
St AI<HATOM alors 
St A5 :: (?- €,Al ?A1) ?-) alors 


sinon A1.CVAL :: !Al 
fst 
stnon CAS A2 : P) :: IP; rec INSTANCIER; ree EVAL; 
P iz C!A5 !A2 ?P) 
fst 
app FILTRI 


stnst Al :: C*ALT* ?A1) alors 
tantque Al :: C!Al ?A3) fatre 
(AS A3 A2 : P) :: IP; ree FILTRI; 
P :: C!A3 !A4 !A2 ?P); 
st Al :: © alors CA3 A4) :: CIAS !A1) 
stnon derec 


fst 
ftan 
O :: FAI 
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wi aa a a a ae ee — —— 


stnst Al :: CC/? !A3 ?Ab) ?A1) alors 
st A5 :: (?- C,A3 ?A3) ?-) alors 
(A3 Al A2 : P) :: C'AI !A2 ?P); 
rec APPEND; 
P :: C!A2 ?P); app FILTRI 
sinst Al ::0) alors 
C(A3 : A2) : AS) :: !A5; 
st AY :: O alors T :: !Al 
sinst (AG A5 : P) :: CIAL ?P); rec INSTANCIER; 
C'AND : Al) :: !Al; rec EVAL; P ::C!A5 ?P); 
st Al :: © alors A5 :: C!- ?A5) fst 
fst 
sinon 
CA3) :: !A3; CA3 : A5) :: TAS; 
jusqua A2 :: O fatre 
se A4 :: O alors A2 ES LY 
sinon CAL A5 Au A3 A2 Al : P) :: CIAL ?P); 
ree INSTANCIER; 
C'AND : A1) i: !Al; rec EVAL; 
CAL : P) i: CLY JAS !AH !A3 !A2 SAL ?P) 
fst 
st Y it CJ) alors 
sinon (A5 Au A3 A2 Al : PD :: !P; rec FILTRI; 
P :: (ly ‘AU !A3 !A2 !X ?P); 
st Al :: O alors CY X) :: CA5 IAL) 
sinon derec 


fst 
fst 


A2 1: CX ?A2); (X) iz 1A3.CDR; A3 :: C- ?2A3) 
fiusqa 
AS :: C- ?A5); © :: 141 

fst 
sinsi Al :: C/? !A1) alors (CAL A2) : A5) :: !A3 


sinsi A2<HATOM alors €) :: !Al 
sinon 
(AL A2 Al A2 : P) :: ÇCCHIAI ?-) CIA2 ?-) ?P); 
ree FILTRI; P i: CC!- ?A3) C!- ?AH) ?P); 
St Al :: ©) alors 
sinon (A3 A4) :: C!AI1 !A2); app FILTRI 
fst 
fst 


derec 


RF qe à a ten ame EE a n. 


Au chapitre suivant, nous illustrons dans un cas très simple l'utilisation 
de la méthode des filtres pour spécifier des implémentations. Nous y définirons 
une version restreinte du langage PLASMA, version totalement compatible avec 


VLISP, que nous nommerons M-PLASMA. 


L'implémentation du langage-hôte : VLISP sera décrite de la même façon 


au chapitre 6. 
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CHAPITRE 5 


UNE APPLICATION DU FILTRAGE : SPECIFICATION DE MICRO-PLASMA 


Nous allons à présent montrer comment la méthode des filtres permet de 
spécifier l'implémentation d'une version très simplifiée du langage 


PLASMA, version que nous nommerons MICRO-PLASMA, 


5.1. — PRESENTATION DU LANGAGE PLASMA 


Le langage PLASMA (SMITH 1975a,HEWITT 1975a,1977), et ses proches 
parents SCHEME (SUSSMAN 1975), SMALLTALK-/72 (GOLDBERG 1974, 1976, LEARNING 
RESEARCH GROUP 197547 er DARWIN (STEIGER 1976), sont des dérivés de LISP, 
descendants immédiats du langage PLANNER 73 (HEWITT 1973b, 1974a, GREIF 
1975), et sont des supports d'expérimentation permettant de tester sur des 
cas concrets (génération de plans et gestion de base de donnée : HEWITT 
1975c, système d'animation visuelle : KAHN 1976, métaévaluation : YONEZAWA 
1976a,b, calculs paralléles et synchronisation : GOODMAN 1976), l'ensemble 
des idées rassemblées sous le nom de sémantique des acteurs (HEWITT 1973a, 
1975b). 

Une version expérimentale a été construite en MACLISP au laboratoire 
d'Intelligence Artificielle du M.I.T., essentiellement par macro-génération 


(SHROBE 1976). 


Un acteur étant défini par sa capacité de recevoir et d'émettre des 


messages, la sémantique des acteurs vise 


1) à définir une entité de calcul en termes des messages a 
elle transmise qu'elle peut accepter, et des messages 


qu'elle transmettra en réponse. 


quoique proche de LISP, SMALLTALK est plus précisèment un dérivé de FLEX (KAY 1969) 
tout à la fois langage et machine, totalement orienté sur la visualisation de 
représentations de calculs, et précurseur des actuels projets et prototypes de 
machines LISP (BARBACCI 1971, DEUTSCH 1973, GREENBLATT 1974). 


3 
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Dans l'esprit du lambda calcul, aucune distinction n'est 
faite a priori entre programmes et données. 

On notera que ce point de vue, trés courant en compilation 
est ici une propriété dynamique de l'exécutton des program- 


mes définis en PLASMA 


2) a ne jamais laisser implicites ni l'envoyeur, ni le 
destinataire des messages transmis. Ainsi une transmission 


de messages, ou événement se composera 
. d'un envoyeur e 
. d'une destination d 
. d'un message m 
. d'une continuation c 


la continuation étant l'acteur qui recevra le message m' émis 


par l'acteur d en réponse à m. 


3) ā ne permettre la communication entre acteurs qu'en termes 
de transmissions : un message indüment transmis à un acteur 
provoque la transmission d'un message d'erreur a un acteur 


spécial nommé bureau des réclamations (complaints department). 


4) à être naturellement étendue au cas de calculs parallèles 
(BELLIA 1976) ou au calcul distribué dans des réseaux 
(FELDMAN 1977). 
Tout événement a un nom appelé activateur, équivalent à une 
E , qui définit l'événement de manière unique. 
Ces activateurs sont utilisés pour la coordination de calculs 
asynchrones par un mécanisme spécial de protection de ressour- 


ces partagées : le sertaitzer (HEWITT 1974b, ATKINSON 1976). 


(1) La notion de transactton(ESWARAN 1976) est un concept importé du domaine de la 
programmation de gestion. Flle est essentiellement une technique de remise 4 
jour qui vise à satisfaire les contraintes de consistance d'une base de données, 
que les actions élémentaires de modification pourraient violer temporairement, 
en regroupant toutes les actions d'un processus sous un nom unique, ici celui 
de l'activateur. Ainsi une transaction transforme un état consistant en un autre 
état consistant. 

Cette technique a été utilisée récemment pour spécifier un projet de garbage 
collection incrémentale en INTERLISP (DEUTSCH 1976). 
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5) a la modularité totale : les acteurs communiquent directement 
entre eux et ne dépendent pas d'une entité globale qui répar- 
tirait hiérarchiquement les tâches à effectuer par chaque 
acteur. Un programme en PLASMA est un ensemble d'acteurs 
initialement définis, chacun d'entre eux pouvant créer d'autres 
acteurs, spéclalisés pour une tâche qu'aucun des acteurs 
initiaux ne pourrait effectuer. Aucun état global n'est 


requis, car les informations connues de chaque acteur lui sont 


. ou bien transmises dans un message 
. ou bien transmises «génétiquement» par l'acteur 


qui l'a créé. 


Le langage PLASMA implémente ces conditions en y ajoutant plusieurs facilités 


de programmation, en particulier 


1) la réception de message a lieu par filtrage, ce qui permet la 
transmission de messages à structures complexes. 
2) plusieurs types d'acteurs sont pré-définis, en particulier la 


séquence permettant ainsi 


. le filtrage sur segments 
. la construction aisée d'acteurs de type queues, piles, bags 


ou ensembles. 


3) un acteur spécialisé pré-défini : la cellule, unique acteur 
permettant des effets de bord, nécessaire à la spécification des 
primitives de synchronisation. 

4) un acteur réalisant l'appel par nécessité : delay (VUILLEMIN 1974, 
FRIEDMANN 1976b, HENDERSON 1976). 
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5.2.- RELATIONS DE PLASMA AU LAMBDA-CALCUL 


Le langage PLASMA implémente essentiellement un lambda calcul avec appel 
par valeur. Il en partage les caractéristiques de localité par la portée lexico- 
graphique des variables, par la non-distinction entre structures de controle et 
structures de données, par la réalisation de la règle de substitution par asso- 
ciation d'un acteur à sa fermeture lors de sa création, par la transparence 
réferentielle de chaque acteur (a l'exception de la cellule), non dépendant 
des modifications d'un état global. 


Il s'en écarte cependant 


1) par l'admission d'effets de bord sur la classe des cellules 

2) par l'accent mis sur le mécanisme de transmission de messages 
plutôt que sur les règles de substitution 

3) par l'adjonction de primitives de protection et de synchronisation 
comme les serializers, difficiles à exprimer dans une sémantique 
de substitution 

4) par la possibilité d'echec d'une transmission, un acteur rejetant 
le message transmis, en l'envoyant au complatnts department 

5) par l'absorption des notions d'arguments et de valeur retournée 
d'une fonction dans celle de message. Cette altération du caractere 
fonctionnel, ajoutée 4 la possibilité de transmettre des messages 
complexes, est en elle-même une solution au problème posé en LISP 


par le retour de valeurs multiples (cf §6.2.12). 


5.3.- POURQUOI IMPLEMENTER MICRO-PLASMA ? 


Notre implémentation de MICRO-PLASMA vise 


1) A montrer que la spécification par filtrage permet de décrire 
L'implémentation d'un langage 4 sémantique trés différente de 


celle de LISP 
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2) a obtenir un interprète plus efficient et moins encombrant 
que l'interprète PLASMA du M.I.T. qui procède par semi- 
compilation en LISP des programmes PLASMA suivie d'une 
exécution interprétative (STEELE 1976b). 

En laissant de côté les notions de cellule et de serializer, 
nous avons extrait de PLASMA les deux constructions qui nous 


paraissent les plus intéressantes 


la notion d'acteur 


. la transmission de message 


et nous les avons implémenté au méme niveau que VLISP en les 
rendant compatibles, obtenant ainsi une extension originale de 
LISP trés peu encombrante et beaucoup plus rapide que le 


systeme PLASMA original. 


3) a montrer que le mécanisme de transmission de message en 
PLASMA et en SCHEME, capable d'interpréter itérativement 
des transmissions équivalentes à des appels de procédure 
post-récurstfs, gère de façon inefficace le cas des appels 
post-récurstfs enveloppés (cf. §7.2.2), en préservant 
inutilement dans la fermeture des acteurs créés, des asso- 
ciations variables-valeurs qui ne seront jamais utilisées. 
Nous proposerons en VLISP au §7.3.2 une solution efficace 


a ce problème., 


5.4.- STRUCTURE DE MICRO-PLASMA 


Il s'agit essentiellement de l'intégration a LISP 


. de la notion d'acteur 


. du mécanisme de transmission de message par filtrage 
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Un acteur aura la structure 
(=> un-filtre un-corps) 
dans laquelle 


. le corps est une suite d'expressions LISP ou de Éransmisstions 


. le fritre sera une liste de couples 


(nom, : fente, ... nom: fente ) 
avec 
| variable 
ente = i : 
f [suite de variables] 
et tel qu'au moins un nom = CONT 


et fente. est une continuation. 
] 


Une transmtsston aura la structure 

CSEND destinataire enveloppe) 
ou indifferemment 

(destinataire <= enveloppe) 
dans laquelle 


. destinataire est un acteur 


. enveloppe sera une liste de couples 


(rom, : pièce, ... nom: pièce ) 
n n 


avec 
PS 
pièce = |[suite d'expressions-LISP] 

M acteur 


La primitive SEND est l'unique moyen de communication entre acteurs. 


Nous allons a présent en donner quelques exemples, à dessein très élémentaires, 
mais susceptibles d'éclairer le mécanisme des transmissions et des constructions 
de fermetures, en particulier dans le cas d'acteurs récursifs. Dans ce qui suit 


MICRO-PLASMA sera abrévié M-PLASMA. 
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EXEMPLE |l 
CIS SSYMME 
(=> (MSG: tX YI) CONT: C) 
CC <= (MSG: (C+ X Y) (* X Y)]1)))) 
L'acteur SSOMME est défini initialement, à la boucle supérieure 
de M-PLASMA par la primitive IS. 
Une transmission à cet acteur pourra être 
(SEND $SOMME (MSG: [2 3] CONT: $TOP)) 
au cours de laquelle 
1) les valeurs 2 et 3, et l'acteur STOP seront 
respectivement liés aux variables X, Y et C 
des fentes du filtre de SSOMME 
2) une enveloppe constituée de la somme et du 
produit de X et Y sera alors envoyée par 
SSOMME à l'acteur STOP 
EXEMPLE 2 
L'acteur SEXP reçoit un couple d'entiers positifs b et e et 
calcule b 
| <--------- (IS SEXP 
(=> (MSG: [B EJ CONT: C) 
CIF (= E 0) (C <= (MSG: 1)) 
(SEND SSELF 
(MSG: CB (AUZ E 2)17 CONT: 
A aa aa a aa a a i ea a (=> (MSG: Y) 
CIF CEVEN E) (C <= (MSG: Cx Y V))) 
(SEND C 


(MSG: (x BY Y¥)))))))))) 
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SS - oh SR NE + ser re 


La transmission 
(SEND SEXP (MSG: [5 3] CONT: SSUITE)) 


provoquera l'envoi de 125 à l'acteur SUITE. 


On observera que nous avons complété M-PLASMA par la primitive VLISP 
SELF, ici représentée par l'acteur $SELF qui désigne dynamiquement l'acteur 
courant. 

L'acteur défini en ligne 2 sera créé par EXP, et son environnement, 
ici représenté par B, E et C en variables libres sera clôturé dans une 
fermeture. Cette fermeture sera ici constituée dynamiquement par EXP sous 


la forme de l'enveloppe 
(CLOS: “CB val.) CE val_) CC val.) 


B, E et C étant couplés à leurs valeurs au moment de la création de l'acteur 


cloture. 


En désignant par y le code de l'acteur en ligne 2, examinons les 


transmissions successives, consécutives à la transmission initiale 


(SEND SEXP (MSG: [3 7] CONT: STOP)) 

CSEND SEXP (MSGS 13:3) CONT: C-e (CLOS: CB 3)-CE 7) CC STOP) WFir) 
CSEND SEXP (MSG: [3 1] CONT: (=> (CLOS: CB 3) CE 3) CC BD yI=R2 DD 
(SEND SEXP (MSG: [3 0] CONT: (=> CCLOS: CB 3) CE 1) CC 622) y)2=Ps )) 
(SEND 83 (MSG: 1)) 

(SEND Pa (MSG: 3)) 

(SEND Bi (MSG: 27)) 

(SEND STOP (MSG: 2187)) 


Cette interprétation est récurstve : chacune des valeurs de C dans 
la fermeture comporte la fermeture de l'étape précédente. 

Le mécanisme de pile, formellement absent de M-PLASMA est ici reporté 
sur l'imbrication des fermetures, une fermeture nouvelle enfermant les 


précédentes est construite à chaque étape descendante du calcul. 
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EXEMPLE 3 


L'acteur SRAC, calculant la racine carrée par défaut de l'entier 


N, sera au contraire interprété ttératitvement. 


l'es (IS SRAC 
(=> (MSG: N CONT: C) 
CSEND 
2 mmummumm (=> (MSG: CN KI CONT: D) 
CIF (< N K) 
CSEND D (MSG: (QUJ <- K 1) 2))) 
CSSELF <= (MSG: fC- N K) (+ K 2)] CIN Ta 
(MSG: [N 13 CONT: C)))) 


En effet, l'acteur de la ligne 2 ne créé pas de nouveaux 


~ 


acteurs, et se contente, à chaque étape de transmettre la 


méme continuation que celle qu'il avait initialement recue. 


Quelque soit la valeur de N, SRAC ne crééra qu'un seul 


acteur. 


EXEMPLE 4 


L'acteur S5APPEND reçoit un couple de listes X et Y, et 
calcule la concaténation d'une copie de la première à 


la seconde. 


1 ---- (IS $APPEND 
(=> (MSG: [X VI CANT: C) 
CIF (NULL Y) (SEND C (MSG: Y)) 
CSAPPEVD <= 
(MSG: CCCDR X) vy 
CON Ts 
2 =e ee we mm ee ee — (=> (MSC: Ap) 


D)))) 


(SEND C (MSG: (CONS CCAP Y) SVEND 
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oo PR POI En et nn le tent) 


On notera à la ligne 2 qu'un nouvel acteur est créé à chaque 


étape descendante du calcul, préservant dans sa clôture 
(CLOS : CX val) CY val Y ) CC alJ) 


les valeurs courantes de X, Yet C. 
Cependant Y est préservé tnuttlement : il n'est pas utilisé 
par l'acteur créé. De plus la préservation de X est en principe 


inutile, l'acteur APPEND étant équivalent ā la fonction LISP 


| --------- (DE APPEND (X Y) 
CIF CNULL X) Y 
2 mm ——— (CONS CCAR X) CAPPEND CCDR X) Y)))) 


Lors de l'appel CAPPEND (CDR X) Y), après évaluation des 
arguments (CDR X) et Y, les valeurs courantes de X et Y 
seront devenues inutiles, n'étant plus jamais utilisées. 
Bien entendu, dans la version M-PLASMA, la continuation 

C doit être préservée, pour garantir les retours récursifs 
successifs. 

Nous avons donné à ce problème, non résolu dans le cadre 
des langages PLASMA, SCHEME ou DARWIN, une solution implé- 
mentée dans le cadre de VLISP que nous présenterons au 


$7.1 sous le nom d'interprétation semi-ttéralive. 


5.5.7 IMPLEMENTATION DE M-PLASMA 


Nous distinguerons deux phases de traitement de chaque acteur 


1) pré-traitement 


quand un acteur est défini par la primi- 
tive IS, il subit d'abord, ainsi que tous les acteurs 
qu'il englobe lexicographiquement, un pré-traitement qui 


lui donne un format interne qui en permettra l'interpré- 


tation. 

2) transmissions : puis la première transmission évaluée 
lancera le calcul qui consistera en transmissions d'un 
acteur à l'autre et en créations de nouveaux acteurs. 
Cette phase sera interprétée par le noyau de procédure 
que nous allons définir en langage FILTRE. 

5.5.1.- PRE-TRAITEMENT 


Il est effectué une fois pour toutes au moyen de fonctions VLISP que nous 


donnerons à l'appendice 4. 


Il consistera a 


1) 


2) 


3) 


transformer les expressions de type [sutte-d'expresstons } 


en (LIST suite-d'expressions) 


Ce traitement est assuré à la lecture par macro-génération. 


transformer les expressions de type (x <= y) en (SEND x y). 


Ce traitement est assuré par la fonction PRE 


à associer à chaque acteur l'ensemble LOC: de ses variables 
de filtre et des LOC: des acteurs dans lequel il est lexi- 


cographiquement imbriqué. Ce traitement est assuré par les 


fonctions SCAN-RECEIVER et SCAN-MSG. 


EXEMPLE 


L'acteur SAPPEND de l'exemple 4 sera ainsi prétraite 


(=> (LEC: CX Y C)) (MSG: (LIST ¥ Y) CENT: C) 
CIF- (NILE XI SEL C CTOS 29 
(SENC $SAPPENE 
(MSG: (LIST (CDP Y) Y) CANT: 
Cas (LOCS X Y CZI CSG I 
(SEND C (MSG: (CANS CCAP YX) 79999900) 


L'acteur prétraité deviendra, sous forme d'une liste, la 
valeur VLISP de son atome-nom. Ce sera 14 l'effet de la 


fonction VLISP IS donnée à l'appendice 4. 


5.5.2.— TRANSMISSIONS 


eve me ae vhi Sete FE sæ ie mind Ft nt Mug t 


Chaque transmission utilisera quatre registres 


YSENDER : recevra l'acteur responsable de la transmission 


#TGT + recevra le destinataire ou ctble de la transmission 
#MSG : recevra l'enveloppe évaluée de la transmission 
#LOC - recevra la liste (LOC: (?-)) des variables locales a l'acteur cible: 


La transmission effectuée par la primitive SEND consistera à évaluer l'enveloppe 
au moyen de la primitive EVAL-MSG. Le controle sera alors passé à la primitive 


DO-IT-AGAIN qui se chargera 


de filtrer l'enveloppe évaluée par le filtre de la cible 
au moyen de la primitive MATCH-PACK | 
d'affecter les registres de transmission #SENDER, #TGT, 
YMSG, #LOC 
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. d'affecter, si l'acteur cible est une fermeture, les variables 
de sa liste (CLOS: (?-)) à leurs valeurs clôturées 


de lancer l'évaluation VLISP du corps de l'acteur. 


5.5.3.- INITIALISATIONS ET BOUCLES-SYSTEME EXTERNES 


L'initialisation des registres de transmission sera effectuée par la 


primitive M-PLASMA 


M-PLASMA = 


C'STOPLEVEL ©) 'MSG: C'ENTER 'MPLASMA)) :: C!#TGT !#LOC ?#MSG); 
app DO-IT-AGAIN 


La boucle supérieure systéme de M-PLASMA est constituée des acteurs 


STOPLEVEL, SEVAL et $TOP qui peuvent donc, étant définis en M-PLASMA, être 


~ 


redéfinis a volonté. 


CIS STSPLEUVEL 
(=> (MSG: X) 
(PRINT XI 
(SEND SEVAL (MSG: (PRE (CR EAD)) CONT: $TOP)))) 


CIS STØr 
(=> (MSG: X) 
CPRINT "ANSWER "IS x) 
(SEND STOPLEVEL (MSG: *(M=-PLASMA T@P))))) 


CIS $EVAL 
C=> (MSG: E CONT: C) 
CIF CEC CCAR E) *SEND) (EVAL E) 
(SEND C (MSG: (EVAL E)))))) 


L'acteur STOPLEVEL imprime un en-tête, prétraite une donnée lue (définition 
d'acteur, envoi d'une transmission, ou expression VLISP), et envoie cette 


donnée à l'acteur SEVAL, muni de la continuation STOP. 
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SEVAL effectue la transmission si la donnée en est une, sinon évalue l'expression 
VLISP soumise, et en envoie le résultat à la continuation STOP qui l'imprime et 
retourne le contrôle à l'acteur $TOPLEVEL. Cet acteur S$EVAL assure la compati- 


bilité avec VLISP. 


5.5.4.- EVALUATION DE_L'ENVELOPPE 


C'est l'objet de la primitive EVAL-MSG. 


EVAL-MSG ubr = 
st Al :: © alors 
(NIE SANDER TAQ CAD = PD LES 
tantque Al :: CIAS !A4 ?-) faire 
CCA4 : NIL) A3.PLIST A2 Al A3 : P) 
C!A4 (2- PACKAGER !Al ?-) ?P); 


pec APPLY; 
(CALL © NIO © P) Sr CAZ TAU Cl]. PAID DAS PDs 
(A3 : A2) :: 'A4.CDR 
ftan 
P :: CC!- 2A1) ?P) 
fst 
derec 


EVAL-MSG reçoit dans Al une enveloppe non-évaluée, et construit une nouvelle 
enveloppe comportant les mêmes noms et dans laquelle les pièces sont évaluées 
par des primitives associées à ces moms. 
Etant donné l'enveloppe 

(nom : pièce, ... nom: pièce, ) 
EVAL-MSG construira 

(nom : CAPPLY nom, : pièce, ) ... nom: CAPPLY nom: piece, )) 
Ce mécanisme permet à l'utilisateur de définir lui-même la maniere dont 


les messages seront évalués. Ce mécanisme est voisin du style de traitement 


de paramètres dans le langage MDL (GALLEY 1975). 
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Une primitive standard très importante, d'évaluation de pzéce est CONT: 


construira une fermeture, si sa piece reçue dans Al est un acteur. 


SL A1<HATOM udors AIL.CVAL :: ‘Al 
sinon C#LOC:Al) :: C!A2 (=> ?A1) ?A3); 
jusquaA2 :: ©) faire 
A2 :: C!A4 2A2); 
CCA4 AU,CVAL) : A3) :: !A3 
fjusq 
Chee CICLOS: A3) ALS 27 SAT 
fst 


derec 
Etant donné, dans une enveloppe, le couple 
(?- CONT: (=> ?-) ?-) 
la primitive CONT: construira un nouveau couple 
C?- CONT: (=> CCLOS: ,y) ?-) ?-) 


avec, si #LOC = Cv... vw) 
CCv, VALV,) 442 Cm VAL, )) 


T 


qui 


Bien entendu, rien ne s'oppose à ce que le même nom figure plus d'une fois 


dans l'enveloppe, pour spécifier par exemple deux continuations distinctes 


(cf. §3.8). 


5.5.5.- EVALUATION DES_TRANSMISSIONS 


Ce sera l'objet de la primitive SEND 


PEND: cube = 
C#TGT Al) :: CC!A2 !A1) !#SENDER); 
ST AD == (=> 7=) 01or8. A2 2: FKTCT 
stnst Al :: SSELF alors 
sinon A1.CVAL :: !#TGT 
fst 
ree EVAL-MSG; Al :: !#MSG; 


derec 
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SEND initialise les registres #TGT, #SENDER et #MSG, en traitant le cas d'une 


transmission à l'acteur $SELF, et en évaluant l'enveloppe de la transmission. 


5.5.6.- FILTRAGE D'ENVELOPPE 


Ce sera l'objet de la primitive MATCH-PACK. 
Elle reçoit dans Al le filtre de l'acteur-cible, et dans A2 l'enveloppe 
évaluée par EVAL-MSG. 


La règle de ce filtrage particulier exigera ici que chaque nom-de-fente 


~ 


du filtre de l'acteur-cible corresponde à un nom-de-piéce de l'enveloppe, 
mais non inversement. Cette régle asymétrique permet a une enveloppe de 


pouvoir être reçue par différents acteurs. 


MATCH-PACK _ br = 
i St Al :: ©) alors T :: IAI 
sinon CAL A2) :: CC!'A3 !- ?-) C!IA4 !- ?-)); 
st A3 :: ,A4 alors 
(Al A2 Al A2 : P) :: CCl- !- 2ALD (1- !- 2A2) ?P); 
ree MATCH~PACK ; 
P :: CC!- !A3 ?-) C!- !A4 ?-) ?P); 
st Al :: C) alors 
sinon st A3<HATOM alors A4 ::,!A3,CVAL 
sinon A3 :: Cl- ?A3); 
jusque A3 4510) Favre 
CAS: Al). > COVAT. PAS) CA? PAMS; 
A2 ::!'AI.CVAL 


T :: TAI 


fst 

derec 
Chacune des variables: du filtre se verra affecter en valeur VLISP, le 
résultat de l'évaluation des pièces de l'enveloppe. 
On observera que la non-réussite du filtrage est considérée et traitée par 


le système comme une erreur. 
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5.5.7.- BOUCLE-SYSTEME_ INTERNE 


C'est la primitive non-terminante DO-IT-AGAIN qui se chargera, à chaque 


transmission 


de remetttre #LOC å jour 

d'affecter les variables VLISP par les valeurs clôturées si 
l'acteur-cible est une fermeture 

de faire filtrer l'enveloppe évaluée par le filtre de la 
cible 


enfin de lancer l'évaluation VLISP du corps de la cible. 


DO-IT-AGAIN 


Subr å 
repeter st #TGT :: CCCLOS: !A1) ?#TGT) alors 


jusqua Al :: O fatre 
AT 222 "CGA. AS) SAL) 
A3 :: 1A2.CVAL 
fjusq 
Per 
HTGT :: CCLOC: !#LOC) AL ?#TGT); 
CHMSG A2 : P) :: C!A2 ?P); 
rec MATCH-PACK; 
CHIGT : P) :: CIAL THTGT PP); 
rea PROGN 
frep 


Une propriété générale des langages de type PLASMA est qu'il est absolument 
indispensable que le traitement des acteurs-fermetures précède le filtrage 
d'enveloppe. 

Si cet ordre n'était pas respecté, une fermeture qui se serait envoyé une 
transmission à elle-même risquerait de boucler, par non-modification des 
valeurs clôturées dans la fermeture. 

On trouvera à l'appendice 4 le listing ` du système M-PLASMA donné en 


VLESP: 
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CHAPITRE 6 


VLISP ET SON IMPLEMENTATION 


Le langage de description d'implémentation FILTRE a été originellement 
conçu pour spécifier notre système LISP : VLISP. C'est la description détaillée 
de celui-ci qui va faire l'objet de ce chapitre. 

Depuis 1972, VLISP a été mis en place sur plusieurs mini-ordinateurs 
anciens et récents, en particulier CAB 500, CAE 510, T1600 sous systéme BOS/D 
(GREUSSAY 1972, 1975). Une implémentation sur une configuration plus importante 
PDP 10 modèle KII0 sous système TOPS, a été également réalisé (CHAILLOUX 1976, 
1977). C'est l'implémentation sur T1600 qui sera plus particuliérement décrite 
dans cette section. 

Etant utilisé intensivement, tant par ses implémenteurs, qu'en pédagogie 
et en recherche, VLISP est en évolution constante : aussi bien pour satisfaire 
à des besoins nouveaux (synthèse automatique de programmes d'analyse musicolo- 
gique : GREUSSAY 1973, animation visuelle sur écran couleur : AUDOIRE 1976, 
Système de correction et d'amélioration de programmes : WERTZ 1976, méta- 
évaluation : GOOSSENS 1977), que pour l'essai de nouvelles extensions de type 
CONNIVER (GREUSSAY 1976 ) et PLASMA (cf. chapitre 5). 

VLISP est principalement utilisé pour la pédagogie et la recherche 4 
l'Université Paris 8-Vincennes. Il est également utilisé dans plusieurs autres 
laboratoires, en particulier à 1'IRCAM, à l'Institut de l'Environnement et à 
l'Institut de Programmation à Paris, à l'Université Paul Sabatier à Toulouse, 
au laboratoire de Psychologie Expérimentale de l'Université d'Aix-en-Provence. 
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Il sera mis en place prochainement à l'Open University en Grande-Bretagne. 


Ce chapitre décrit tout d'abord l'organisation des zones de données 
et de contrôle, puis, en langage FILTRE, décrit le noyau de l'interprète, 
le statut des variables, et le type des fonctions et macro-fonctions. 
Suivent les implémentations des principales fonctions de contrôle classiques, 
puis celles uniques en VLISP : ESCAPE pour le saut généralisé, SELF pour 
rendre toute lambda-expression récursive, CLOSURE et MULTIPLE respectivement 
solutions en VLISP au problème du FUNARG et à celui des fonctions 4 valeurs 
multiples. 

Ce chapitre s'achéve sur les choix d'implémentation comparés de 
VLISP T1600 et VLISP PDP 10, et sur une comparaison des zones et primitives 
de contrôle VLISP avec celles de MACLISP, INTERLISP et LISP 1.6. 
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6.1.- ORGANISATION MEMOIRE 


6.1.1.- STRUCTURE DE LA MEMOIRE 


La mémoire de VLISP se divise en cing zones 


1) la zone de l'interprète, comprenant les tables syntaxiques, 
les tampons et programmes d'entrée-sortie, et les continua- 


tions de l'interprète proprement dit. 


2) la zone des atomes non-numériques, limitée supérieurement 


par le pointeur HATOM. 


3) la zone des listes et des nombres, limitée supérieurement 


par le pointeur HLIST. 


4) la zone de contrôle, cette zone étant le plus souvent gérée 


comme une pile, limitée supérieurement par 


5) la zone des programmes compilés et assemblés des utilisateurs 


En VLISP T1600 ces zones sont consécutives en mémoire. 


Z. INTERP 
Z. ATOMES 

4——— HATOM 
Z. LISTES 

aoa HLIST 


Z. CONTROLE 


Un élément de liste ou un nombre occuperont deux mots de 16 bits consécutifs de 
la zone des listes. Le type, atome ou liste d'un objet est donc déterminé par 


son adresse d'implantation. 


Dans le système VLISP TI600, les dimensions des zones atomes, listes, et controle 
sont modifiables dynamiquement sur une intervention de l'utilisateur, dans la 


limite des ressources disponibles. 


6.1.2.- ORGANISATION DE LA ZONE DES ATOMES 


— oo eee sa ee ee ee ee els cee en ore Genie et ee ee ee ee ee ee ee ee ee A a oe tnt 


Cette zone, en VLISP, se répartit en quatre sous~zones. 


1) les atomes pré-définis, qui sont les noms de fonctions 
standard de type SUBR, LSUBR, MSUBR. Cette sous-zone est 


limitée supérieurement par le pointeur HSUBR. 


2) les atomes pré-définis qui sont les noms de fonctions standard 
de type FSUBR, sous-zone limitée supérieurement par le pointeur 


HFSUBR. 


3) les atomes pré-définis qui sont des constantes standard : NIL, 


QUOTE, T, LAMBDA, EXPR, FEXPR, MACRO. 


4) les atomes qui sont définis par l'utilisateur : constantes, 


variables et noms de fonctions 


SUBRS 
LSUBRS 
MSUSRS 


en SUB 
FSUBRS 


ee, AOUR 
CONSTANTES 
PRE-DEFINIES 


ATOS. DE 
L'UTILISATEUR 


Sa ATOM 


En VLISP T1600 ces sous-zones sont consécutives en mémoires. Le type 
(cf. §6.2.4) des fonctions standard est défini par l'adresse d'implantation 
de leur atome-nom. Cette information de type est ainsi déterminée à partir 
de la zone contenant l'objet, et non pas par la présence ou l'absence d'un 
indicateur. Cette méthode très peu encombrante est bien adaptée à l'implémen- 
tation de LISP dans un espace mémoire restreint, et à faible capacité 
d'adressage. 
En VLISP PDPIO ot les restrictions en espace mémoire sont moindres, un 
indicateur de type est stocké dans le demi-mot gauche de la zone CODE 


de l'atome-nom de la fonction. 
6.1.3.- IMPLEMENTATION DES ATOMES 


Un atome sera une suite de mots consécutifs en mémoire comprenant 


1) deux mots, CVAL et PLIST, pouvant contenir l'adresse d'un 


atome ou d'une liste. 


2) un mot : CODE pouvant contenir l'adresse d'une continuation 


de l'interpréte. 


3) une zone : NOM pouvant recevoir une chaîne de caractères 


qui rendra imprimable le nom de l'atome. 


CODE PLIST 


NOM 


Atome de fonction standard 


CVAL | PLIST 


NOM 


Constante standard 
ou 
atome de l'utilisateur 
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En VLISP T1600, les zones CVAL et CODE sont confondues om 


Un atome x , pré-défini ou non est une constante si 
x.CVAL = x 


Les zones CVAL et PLIST sont organisées en doublet et sont accessibles de 


la même façon qu'un élément de liste 


(CAR x) = x.CVAL 
(CDR x) = x.PLIST 


Les fonctions CAR et CDR sont donc définies avec des arguments atomiques. 

Le doublet CCVAL:PLIST) d'un atome est dès lors modifiable par les fonctions 
RPLACA, SET et SETQ pour la zone CVAL, et par la fonction RPLACD pour la 

zone PLIST. 


La zone PLIST des atomes standard pourra contenir des informations 


intéressantes sur l'état de l'interprète, ainsi l'évaluation de 
CCDR 'REM) 


livre le nombre de doublets disponibles depuis le dernier garbage-collecting. 


6.1.4.- ORGANISATION DE LA ZONE DE CONTROLE 


Cette zone joue essentiellement le rôle d'une pile de récursion. 


Elle contiendra 


1) des adresses de retour, des valeurs temporaires préservées, 


et des expressions en cours d'évaluation 


(1) Ces zones sont au contraire distinctes en VLISP PDP 10, et des fonctions 
standard de modification de la zone CODE permettent une certaine compati- 
bilité avec d'autres systèmes LISP, où les mêmes fonctions peuvent avoir 
des noms différents, notamment MACLISP et INTERLISP. 


nr A LE 


2) 


3) 


plusieurs types de vecteurs 


2.1) vecteurs de LIAISON : cf. §6.2.3 
(IVAR !VAL ?- (marq ?LLIEN) ?-) 


permettant de gérer préservation et restitution 
des liaisons de variables 


2.2) vecteurs d'APPLICATION : cf. §$6.2.1 
(ENVELOPPE ?VEC-LIAISON ?-) 


utilisés par SELF ainsi que pour interpréter 
itérativement certains appels récursifs 


2.3) vecteurs de PROG : cf. $6.2.8 
C!ETIQ !CONT ?- ?VEC-LIAISON !PLOC !PETIQ ?-) 


utilisés dans le traitement des formes PROG 


2.4) vecteurs d'ESCAPE : cf. §6.2.9 
C!VAR-ESC !VAL-ESC (marq ?LLIEN) !PLOC !PETIQ ?-) 


utilisés dans la fonction ESCAPE 


(1) 


des auto-pointeurs chaînage des vecteurs de LIAISON et 


des vecteurs PROG. 


Des accès à des sous-sommets de profondeur quelconque p2uvent être nécessaires 


(1) La présence 


BLAM-liste ( 


PAU PIN 


accès par position 

exemple : P :: C!- !AI ?-) 

Ce type d'accès sera très facilité sur des ordinateurs tels que 
le PDP 10, permettant un accès indexé direct à la pile. Sur 
T1600, il sera nécessaire de transférer au préalable le registre 


pointeur de pile K dans un des registres de base L ou W 


accès par référence 
exemple : P :: (?- reference A1 ?-) 


nécessitant une recherche. 


d'auto-pointeurs fait de la liste de contrôle de FILTRE une 


EDWARDS 1963, FENICHEL 1969), dont la forme la plus simple 
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La notation FILTRE ne fait pas d'hypothése sur l'implémentation de la pile 
vecteur ou pile-liste. En VLISP T1600 et PDP 10, c'est la première alternative 
qui a été choisie pour des raisons d'efficacité. Une pile-liste aurait induit 

des délais difficilement acceptables,dus à la gestion de pointeurs et à l'augmen- 
tation de la fréquence des garbage-collections. Cependant la pile n'en 

reste pas moins accessible à l'utilisateur : nous donnons à l'appendice 5 la 


fonction d'impression de pile utilisée pour la mise au point en VLISP T1600. 


Au §7.4.2 nous examinerons la structure dynamique de la pile de récursion de 
VLISP, en lui donnant une représentation abstraite sous forme de «régles de 
vérifications», pour décrire l'interprétation itérative de plusieurs classes 


d'appels récursifs. 


6.2.- DESCRIPTION DE L'INTERPRETE 


6.2.1.- LE NOYAU 


La boucle-ractne-LISP est la continuation exceptionnelle de tout 
filtrage inconditionnel. Elle devient la continuation présente en cas d'échec 


du filtrage. 


Le mode EVALQUOTE étant tout à la fois une incommodité et une source de 


confusion, l'interpréte VLISP fonctionne naturellement en mode EVAL, 


BOUCLE-RACINE=LISP = 
repeter rec READ ; 
ree EVAL ; 
ree PRINT 


frep 


Le rôle principal d'EVAL et APPLY est le lancement des fonctions standard par 
l'expression : app F.CODE. APPLY et EVAL peuvent également lancer des SUBRS et 
LSUBRS (cf. §6.2.4.), la liste des arguments évalués est dans A4, les premiers, 
seconds et troisiémes éléments de cette liste sont distribués dans Al, A2, A3, 


pourvoyant ainsi aux fonctions standard 41, 2 ou 3 arguments. 


EVAL déploie les MACROS (cf. §6.2.5) et lance les FSUBRS, avec dans Al la 


liste des arguments non-évalués. 


6.2.1.1.- eval 


< 
D 
r 
it 


st Al<HATOM alors AI.CVAL :: !AI 
stnst Al :: {“ALT* (nombre ?-) (QUOTE !A1)) alors 
sinon CAL Al) :: C!A2 C!F ?A1)); 

EVAL2 


st F<HATOM alors 
st F.PLIST :: C?- EXPR !F ?-) alors 
stnst F.PLIST :: (?- FEXPR !F ?-) alors 
CF A1) :: C!AI ?A4); app APPLY 


stnst F.PLIST :: €?- MACRO !F ?-) alors 
CF CA2 : NIL) 'EVAL : P) i: CIAL !A4 ?P); 
app APPLY 

stnst FSHSUBR alors Cmarg : F) :: IF 


stnst F<HFSUBR alors app F.CODE 
sinon CF F.CVAL) :: C!VARESC !F); app EVAL2 


fst 
fst 
CF : P) :: !P; rec EVLIS; CAL : P) :: CIAL !A1 ?P); 
St Al :: Cmarq ?F) alors 


A4 :: CIAL !Al !A3 ?-); app F.CODE 
stnon app APPLY | 
fst 
Fer 


derec 


Lorsque le premier élément de la forme à évaluer est un atome : 


1) si c'est le nom d'une EXPR : les arguments sont évalués 
et main est passée a APPLY 

2) si c'est le nom d'une FEXPR : APPLY est alors directement 
invoquée 

3) si c'est le nom d'une MACRO : APPLY reçoit la définition de 
MACRO et son appel, et retourne le résultat de l'application 
à EVAL 

4) si c'est le nom d'une SUBR : les arguments sont évalués et 


celle-ci est lancée 


5) si c'est le nom d'une FSUBR : lancement direct de celle-ci 
6) sinon, faute de disposer de l'information suffisante pour 
savoir si les arguments doivent être évalués, la CVAL de 
l'atome est extraite, et la continuation EVAL2 est relancée. 
L'atome est cependant préservé dans VARESC pour permettre 
l'implémentation de ESCAPE (cf. §6.2.9). 
Lorsque le premier élément de la forme à évaluer n'est pas atomique, EVAL 
suppose par défaut qu'il s'agira d'une EXPR ou d'une SUBR, les arguments 


seront évalués, et main est passée à APPLY. 


6.2.1.2.- apply 


APPLY = 
repeter 
st A1<HATOM alors | 
st Al.PLIST :: (?- {*ALT* EXPR FEXPR} !Al ?-) alors 
stnst Al.PLIST :: (?- MACRO !- ?-) alors 
CAIL AY Al : A) :: CIF !Al ?A2); 
app EVAL2 
stnst AlsHSUBR alors 
(Al : A4) :: CIF !A1 !A2 !A3 ?-); app F.CODE 
stnst AI<HFSUBR alors 
CAL : A4) :: CIF 2A1); app F.CODE 
sinon A1.CVAL :: !Al 
fsı 
[ edanan stnst CA4 : Al) :: C!Y LAMBDA !X ?A2) alors 
app LIER; CA2 Al : P) :: C!'AI ?P); rec PROGN; 
APPLY3 = 
P iCle PP); app DELIER: derece 
sinon (A4 : P) :: IP; rec EVAL; P :: C!AH ?P) 
fst 


frep 


APPLY doit trouver dans A4 une liste d'arguments, et dans Al une expression 
qui directement ou indirectement devra être une lambda-expression, ou le nom 


d'une SUBR ou d'une FSUBR. 


Si APPLY trouve dans Al le nom d'une EXPR, l'expression associée à cet indicateur 


sur la P-liste est extraite. Nous aurons les possibilités 


1) (EXPR !\-expression) : les variables locales sont alors liées, et le 


corps de la A-expression est évalué 


2) (EXPR !nom-de-SUBR) : ce qui est une façon de rebaptiser les fonctions 
standard 
3) (CEXPR !variable) - la CVAL de la variable est extraite et APPLY 


est relancée 
et de même si c'est le nom d'une FEXPR qui est trouvé, (2) devenant 


2') CFEXPR !nom-de-FSUBR) 


Si APPLY trouve dans Al le nom d'une MACRO, le traitement est équivalent au 


passage direct à EVAL de la MACRO appliquée a ses arguments. 


Enfin, si APPLY trouve dans Al le nom d'une SUBR ou d'une FSUBR, celle-ci est 
lancée. Sinon l'évaluation du contenu de Al est demandée, apres quoi APPLY 


est relancée. 


Nous examinerons au §6.2.3 les continuations LIER et DELIER, responsables de 


la sauvegarde et de la restitution des liaisons des variables. 


Par souci d'alléger l'exposé de cette section, nous avons donné dans le cas 
du traitement de lambda-expressions une version très simplifiée de 1'APPLY 
VLISP. Cette version supporte la fonction SELF. Nous examinerons en détail 
au §7.3.2.2 la version réelle de 1'APPLY VLISP à propos des interprétations 


itératives d'appels récursifs. 


6.2.1.3.- evlis et progn 


EVLIS = 
st Al :: ©) alors 
sinon (NIL : NIL) :: !A2; CA2 A2 : P) :: IP; 
tantque CAL Al : P) :: CCIAL !- ?-) ?P) faire 
ree EVAL; 
CAL : NIL) :: !Al; P :: CC!- 2A2) !A3 ?P); 
(Al A2 Al : P) :: C!A3.CDR !Al ?P) 
ftan 
Al :: C'Al); ree EVAL; P :: C!A3 !A2 ?P); 
CCAl : NIL) : A2) :: CA3.CDR !- ?A1) 
fst 
derec 
PROGN = 


tantque CAL Al : P) :: CCIAL !- ?-) ?P) faire 
rec EVAL; P iz: CC!- ?A1) ?P) 

ftan 

Al :: CIAL); app EVAL 


PROGN et EVLIS sont, en VLISP, les opérateurs de séquenttialité. 


PROGN reçoit en Al une liste de formes à évaluer séquentiellement. La valeur 
de ces formes est ignorée à l'exception de la dernière forme : le contrôle de 


son évaluation est directement donné à EVAL. 


PROGN pourrait ainsi se définir en VLISP 


(DE PROGN CL) 
CIF CNULL CCDR L)) CEVAL CCAR L)) 
CEVAL (CCAR L)) 
CPROGN CCDR L)))) 
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EVLIS reçoit de même en Al une liste d'arguments non-évalués. Elle doit retourner 
à son appelant une liste de ces arguments évalués, liste retournée en Al. On 


notera que cette évaluation est strictement séquentielle. 


EVLIS pourrait être définie ainsi en VLISP 


(DE EVLIS CL) 
CIF CCDR L) CCONS CEVAL CCAR L)) 
CEVLIS CCDR L))) 
(LIST CEVAL CCAR L))))) 


L'implémentation de EVLIS est fondée sur une technique utilisée pour la 


réalisation itérative de fonctions du type 


(DE F CX) 
CIF CNULL X) NIL 
(CONS CG CCAR X)) CF CCDR X))))) 


X étant une liste, et G une fonction quelconque. 
CONS n'étant pas associative et n'ayant pas de fonction inverse, les trans- 
formations de programmes suggérées dans (DARLINGTON 1976) ne sont pas applicables, 


et on procédera comme suit. 


On sait que 


X 


Cx, X, +. x ) 
CCONS x, CCONS x, ... CCONS x NIL) ... D) 
(LIST x x ... x) 
1 2 n 
CCDR CLIST NIL XK eee x )) 


et sachant que CRPLACD Cx. y) 3) = (z. z) 


X = (CDR CRPLACD CLIST NIL) 
CRPLACD CLIST x) ... CRPLACD (LIST xD (LIST x )) aie DOD 


dans lequel nous noterons (LIST x ) et (LIST x ) respectivement bord gauche 


et bord drott de la liste X. 
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La méthode consiste à construire X par accrochage par RPLACD des bords droits 


successifs (LIST x ) LES AST x o) a un bord gauche initial (LIST NIL). 


La structure de contrôle recursive est ainsi reportëe sur une structure de 


donnée avec effet de bord. 


Le nouveau schéma de F sera alors 


(DE F (X) 
(LET (CBG (LIST NIL))) 
CLET CCX X) CBD BG)) 
CIF CNULL X) CCDR BG) 
CRPLACD BD 


CSETQ BD CLIST CG CCAR X))))) 
(SELF (CDR X) BD))))) 


C'est ce schéma qui est implémenté en VLISP pour EVLIS avec Pi SIEVE 


et G = EVAL. En raison de l'appel à EVAL, BG et BD sont préservés dans la pile P. 


6.2.1.4.- Un exemple d'évaluation 


Suivons notre interprète dans l'évaluation d'un exemple. 


Après l'évaluation de 


CSETQ B *GAR) CSETQ A "CCONS)) 


nous aurons 
B.CVAL 
A.CVAL 


CAR 
(CONS) 


IL 


Est alors livrée à EVAL la forme 


CCB A) 'V 'W) 


Nous sulvrons le destin de cette forme en utilisant la notation 


ul donne les valeurs e Sati - des variables V naea E de 
ES ñ n pe n 


l'interprète dans la continuation x. 


122 


(CB A) 'V 'W)} 


eval {Al = 

eval JE = (BA), Al = C'V 'W)} 

eval2 {Al = (B A), AY = (V W)} 

apply (Al = CB A), At = CV W)} 

apply {eval {Al CB AD}, Au = CV W)} 
apply {eval (F B, Al = CAD}, AY = (V W)) 
apply {eval2 {F CAR, Al = CAD}, At = CV W)} 


(marg : CAR), Al = CAD}, A4 = CV W)} 


apply feval2 {F = 
Cmarg : CAR), AY = CCCCNS))}, Ab = CV WD} 


apply feval2 {Al 
apply (eval2 {F 
apply {Al = CONS, A4 = CV W)? 
apply {F = CONS, Al = V, A2 = W, A3 = NIL, Ab = CV W)} 
cee. (ALS Ne Rss 


di ott Ut Gl vb it~ 


H H 


On notera qu'EVAL considère les définitions de fonction de l'utilisateur 
comme prioritaires sur la définition standard. Ainsi l'utilisateur a tout 
loisir de redéfinir une fonction standard. Voici en exemple une redéfinition 


du SETQ simple 4 deux arguments (cf. §6.2.3). 


CDF SETQ CIL) 
(SET CPRINI CCAR 1L)) CPROGN 
(PRINI '=) CPRINT CEVAL CCADR 1L)))))) 


Chaque évaluation d'une affectation de variable provoquera l'impression du 


nom de cette variable ainsi que de la valeur de la variable ainsi affectée 
CSETQ A 'CLE DOME)) 
provoquera 1'impression de 
"A= CLE DOME) 
et A.CVAL = CLE DOME) 


On notera également qu'EVAL est une fonction disponible a l'utilisateur, 


fonction standard de type SUBR (cf. §6.2.4). Ainsi on aura 


(EVAL (ADDI 1)) > 2 
(EVAL 'CADD1 1)) > 2 
(EVAL CREAD)) CADDI 1) > 2 


On observera enfin que la généralité de APPLY induit, pour certaines 


applications, un comportement non-terminant. 


CAR, Al = (CONS), A2 = A3 = NIL, A4 = CCCONS))}, A4 = CV 
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supposons que 
CSETQ G 'CCAR G)) 
alors 
CG G) > CAR 
Mais Si on a 
CSETQ G 'CCCAR G))) 
alors l'application 
CG G) diverge, 


l'évaluation de l'opérateur G redonnant indéfiniment CCAR G). 


Gue caib mem ee ee b ee p ee ee ee p ee ee ee ee ee ee ee ee ee ee HU e 


En VLISP, une lambda-expression est de la forme 
Ch ltste-de-vartables el e2 ...en) 


dans laquelle les el, e2, ... en sont évalués en séquence par la continuation 
PROGN qui retourne la valeur en . Ceci permet d'éviter de réévaluer des sous- 
expressions communes, et introduit une forme de séquentialité plus efficiente 


que celle permise par les formes du type PROG. 


On notera l'absence des formes LABEL qui, en LISP 1.5 autorisaient des définitions 
provisoires de fonctions (elles sont avantageusement remplacées par la construc- 


tion VLISP SELF), ainsi que la disparition des formes du type 
CFUNARG fonction a-liste) 


VLISP étant, comme nous l'avons vu au §3.5, un P-évaluateur, ceci est une 
conséquence du mode de liaison des variables, où la stratégie dite d'élimination 
(BERRY 1971, FISCHER 1972) a été délibérement choisie. 

Une solution au problème des arguments et valeurs fonctionnels, compatible 


avec cette stratégie sera donnée au §6.2.11. 
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VLISP s'écarte des langages de type ALGOL, comme toutes les versions 
de LISP, et de même qu'APL, par le principe de la fluidité des variables 
(cf. §3.5.2). Portée et liaison de variables sont définies dynamiquement et 
non pas lexicographiquement : les dispositifs de type display (RANDELL 1964) 
sont inutilisables en LISP, tant pour la consultation que pour l'affectation 
des variables, une variable ne pouvant pas être associée à une adresse unique 


dans une pile de segments d'activation. 


VLISP se distingue très fortement de LISP 1.5, de même que MACLISP et LISP 1.6 


par 1'abandon des A-listes, et 1'adoption du principe de Liaison superficrelle 


des variables. 


En LISP 1.5 les variables étaient localement liées sur une A-liste, représen- 
table fonctionnellement, pour une A-liste de longueur n , par l'expression 


conditionnelle 


(Ax . st x = var! alors vall sinst x = var2 alors val2 ... 
sinst x = varn alors valn 
sinon erreur-variable-indéfinie 
fst) 
Le principe de la A-liste rendait en LISP 1.5 tres facile la liaison locale 
et la restitution des valeurs des variables, mais était trés inefficiente 
mar (A f ; oc a aa 
tant en consultation qu'en modification et obligeait de surcroit a dıs- 


tinguer deux types de variables 


1) les variables globales dites SPECIALES, affectables par 
RPLACA ou CSETO 


2) les variables de la A-liste, affectables par SET et SETQ 


(1) de surcroît, les A-listes, en encombrant la zone des listes, rendaient 
d'autant plus fréquentes les garbage-collections. Cette objection 
s'applique au schéma proposé par (BAKER 19770) qui tente de faire 
coexister en LISP 1.5 liaisons sur A-liste et liaisons superficielles. 
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En VLISP il n'y a pas de distinction entre variables locales et globales. 
Toutes les variables sont globales et leurs valeurs sont consultables et 
modifiables immédiatement dans la zone CVAL des atomes. La fonction 
d'affectation SETQ peut donc s'appliquer à toutes les variables. Ainsi 
les variables libres sont liées à la racine de LISP qui constitue un 


environnement implicite de liaison pour toutes les variables. 


La C-valeur des variables est, a la lecture de leur atome-nom, initialisée 
avec une valeur spéciale : JNDEFINI ce qui permet de repérer les tentatives 


de consultation de variables non encore affectées. 


C'est APPLY qui, lors de l'évaluation d'une forme de type 
CCA Gs... v ) corps) e ... e) 
1 n 1 n 


ou CCA v corps) e ... e ) 


assure la gestion des liaisons et déliaisons des variables locales à la 


lambda-expression, en appelant les continuations LIER et DELIER. 


LIER = 
(marg SELEN). Pr 2. (TPs 
tantque X :: C!X1 ?X) fatre 
CY X1 X1.CVAL : P) :: CCIXI1.CVAL ?Y) ?P) 
ftan 
St X :: Q alors 
sinon CY X X.CVAL : P) :: CIX.CVAL ?P) 
fst 
P :: ILLIEN; ret 
DELIER = 


repeter P :: C!X ?P); 
st X :: (marq ?LLIEN) alors ret 
sinon P :: C!X.CVAL ?P) 
fst 

frep 


LIER attend dans X une variable (cas des LEXPR) ou une liste de variables. 
Y devra contenir une liste de valeurs a lier localement a ces ou cette 
variables. Comme nous l'avons vu au §6.1.4, les vecteurs de liaison vivent 


dans la pile. Ils sont créés et détruits par LIER et DELIER. 
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. V 

] n reste 
à mi-chemin entre un nombre d'arguments fixe, et un nombre variable 
d'arguments (cas des LEXPRS). A l'appel, les n permiers arguments 


seront liés 4 v ... v, , le reste de la liste d'arguments sera 11é 
n 


reste ` 


CCLAMBDA (X Y . Z) corps) 2 3 5 7 11) 


X sera lié 4 2, Y à 3, et Z à (5 7 11). 


En VLISP T1600, ia gestion des variables est assurée au moyen d'une suite 
chaînée de vecteurs de liaisons, elle même sous-liste de la liste de 
contrôle. 


aoe UE VEN 


VARIABLES 
ET VALEURS 


LLIEN* 
! 


| 


Vecteurs de liaison 


Confrontons sur un exemple les méthodes de liaison de LISP 1.5 et VLISP. 


Supposons que la continuation APPLY devient la continuation présente, avec 


Al 
A4 


Ca CU V W) ?corps) 
(8 (DOME) B) 


En LISP 1.5 nous aurons 
1) avant liaison, l'état de la A-liste, par exemple 
COULFEUD VD Ce S ace 2 
2) après liaison 


(CU.8) CV.DOME) (W.B) CU.FEU) CV.3) CW.-12) ... ) 
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En VLISP T1600 nous aurons 
1) avant liaison : 
U.CVAL = FEU V.CVAL = 3 W.CVAL = -12 
2) après liaison : 


U.CVAL = 8 V.CVAL = CDOME) W.CVAL B 


li 


et un nouveau vecteur de liaison sera formé dans la liste de contrôle 


L'affectation de toutes les variables sera possible en VLISP grâce aux 


fonctions SETQ, SETQQ, et SET. 


SETQ = 
ber tantque CAL Al : P) :: CC!- !Al ?-) ?P) fatre 
rec EVAL; 
P :: CCIA2 !- ?A3) ?P); CA3 Al) :: CIAL !A2.CVAL) 
ftan 
A2.CVAL :: !Al; derec 


VLISP réalise le SETQ multiple 
(SETQ var, exp, ... var exp ) 


De 1 an, l'expression exp, est évaluée et affectée à var. La valeur 
1 


retournée sera celle de exp . 
n 


Cette évaluation est séquenttelle : la valeur d'une occurence de var, dans 
exp, sera la valeur de exp. , contrairement à l'application d'une lambda- 

1 1 
expression et à sa version sous forme de MACRO, LET, qui réalisent l'affec- 


tation parallèle. 


SETQ pourrait s'exprimer en VLISP en termes de SET 


CDF SETQ (X) 
(LET CCVAR CCAR XD) CVAL CEVAL (CADR X))) CREST CCDDR X))) 
(SET VAR VAL) 
CIF REST (APPLY 'SETQ REST) VAL))) 


et SET en termes de SETO 


CDE-SET CX Y2 
CAPPLY 'SETQ CLIST X CLIST QUOTE Y)))) 


L'implémentation de SET sera 


SET cube 7 
(A2 A2) :: CIAL.CVAL !A1); derec 


La primitive SETQQ est identique 4 SETQ mais n'évalue pas les exp, qui sont 


ainsi implicitement quotés. 


SETQQ + br 7 7 2 
tantque Al ::C!A2 !A3 ?A1) faire A3 :: !A2.CVAL ftan 
A3 :; !Al; derec 


VLISP comprend deux formes indirectes d'affectation de variables à valeur de 


liste : NEXTL et NEWL. 
(NEXTL !vartable) 


retourne le CAR de la valeur de la vartable, et réaffecte implicitement la 


variable avec le CDR de sa valeur. 


Soit L,CVAL = M.CVAL = Ça b c) 
l'évaluation de CSETQ X CNEXTL L)) 
donnera X.CVAL = a 
et L.CVAL = (b c) 
et M.CVAL = (a b c) 


NEXTL pourrait ainsi s'exprimer en VLISP 


CDF NEXTL CL) 
(LET CCVAR CCAR L)) CVAL CEVAL CCAR L)))) 
CSET VAR CCDR VAL)) 
CCAR VAL))) 


et sera implémenté comme 


NEXTL ne = 
. Al :: C'A2); A2.CVAL :: C!AI ?A2.CVAL); deree 


La fonction NEWL est symétrique de NEXTL : 
(NEWL !vartable lexpression) 


évalue l'expression, construit une nouvelle liste dont le CAR est la valeur 
de l'expression, le CDR est la valeur de vartable, et affecte cette nouvelle 


~ 


liste à vartable en la ramenant comme valeur. 


Soit L.CVAL = M,CVAL Cb c) 
l'évaluation de CSETQ N CNEWL L 'A)) 
donnera N.CVAL = Ca b c) 
et L.CVAL = (a b c) 
et M.CVAL = (Cb c) 


Si NEXTL et NEWL étaient de type SUBR elles seraient ainsi composables 
CNEXTL (NEWL L yD) = y , 


L.CVAL demeurant constante, et permettent l'utilisation d'une forme limitée 


de stream (LANDIN 1965, BURGE 1975). 
NEWL pourrait ainsi s'exprimer en VLISP 


CDF NEWL CL) 
CSET CCAR L) 
(CONS CEVAL CCADR L)) 
CEVAL CCAR L))))) 


et sera implémenté comme 


NENL cube j 
CAL Al : P) CC!- !A1) ?P); ree EVAL; 
P :: CCIA2 =) ?P); CAL : A2.CVAL) :: !A2.CVAL: 


A2.CVAL :: !Al; derec 
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led + mn i SiS A SS a a AS Se eee 


En VLISP, les fonctions, qu'elles soient standard ou définies par 


l'utilisateur sont distinguées par 


le traitement (évaluation et distribution) des arguments 
des appels 


l'appel explicite ou implicite (macros) 


On distingue en VLISP 11 types de fonctions 


1) SUBRS : fonctions standard de nombre fixe d'arguments évalués 


et distribués 
2) EXPRS =: fonctions de l'utilisateur identiques à (1) 


3) FSUBRS : fonctions standard de nombre quelconque d'arguments non- 


évalués et rassemblés en une liste unique 


4) FEXPRS : fonctions de l'utilisateur de nombre quelconque d'arguments 
non-évalués et rassemblés en une liste unique liée au 


premier argument 


5) LSUBRS : fonctions standard, de nombre quelconque d'arguments 


évalués rassemblés en une liste unique 
6) LEXPRS : fonctions de l'utilisateur, identiques à (3) 


7) MACROS : macros de l'évaluateur (cf. §6.2.5.1) : la valeur résultante 


d'un appel de ces macros sera immédiatement réévaluée 


8) MACIN : macros d'entrée : la valeur résultante d'un appel de ces 


macros sera substituée à cet appel dans le flot d'entrée 


9) MACOUT : macros de sortie : identiques à (8), la substitution étant 


effectuée dans le flot de sortie 


10) MSUBRS : macros-caractères standard. La détection dans le flot de 
lecture du caractère qui est le nom de la M-SUBR provoque 
le lancement de la continuation de l'interprète correspon- 


dante, interrompant ainsi provisoirement la lecture 


11) MEXPRS : macros de l'utilisateur, identiques a (10). 
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Ainsi l'abréviation 'x pour (QUOTE x) est implémentée par une macro de type 


MSUBR qui, si elle n'était pas standard serait ainsi définie 
CMCHAR ' CA ©) CLIST QUOTE CREAD)))) 
En voici un autre exemple. Si on a défini 
CMCHAR = CA (D (REVERSE CREAD)))) 
alors l'évaluation consécutive à la lecture de 
'(a b =(c d e) f g) 
retournera en valeur 
Ca b Ce d c) fg) 


La possibilité de définir des macro-caractéres est nécessaire pour l'implé- 
mentation de dérivés de LISP tels que PLANNER et CONNIVER, qui imposent des 
(1) 


types aux variables des filtres 


Les fonctions de l'utilisateur, méme définies avec n arguments peuvent en 


VLISP être appelées avec un nombre k d'arguments différents 


I) si k>n les arguments supplémentaires seront ou non 


évalués, selon le type de la fonction, puis ignorés 


2) si k<n les arguments de la définition seront initialisés 


commodément a la valeur NIL. 


Cette non-obligation d'identité du nombre d'arguments actuels et formels, 
ainsi que la définition précise par l'implémentation de EVLIS de la 
séquentialité de l'évaluation des arguments d'une fonction EXPR, LEXPR, 


SUBR ou LSUBR, permettent d'utiles effets de bord. 


Ainsi CSET 'X Y CSETQ Y X)) 


échange les C-valeurs des variables X et Y. 


(1) voir (BAUMGART 1972) pour une illustration de l'opacité de lecture des 
programmes MICRO-PLANNER, inhérente 4 la non-implémentation en LISP 1.6 
des macros-caractères. L'implémentation de FILTRE en VLISP en fait elle- 
méme trés largement usage. 
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Ainsi encore si on a évalue 


(SETQ X 'CNULL)) 

CCAR X) > NULL 

CCCAR X)) > T 

CCCAR X) CCCAR X))) > NIL 


6.2.5.- MACROS 


6.2.5.1.-— Macros de l'évaluateur 


VLISP comme LISP 1.6 et MACLISP autorise la définition de macro- 
fonctions. Certaines applications en font un usage intensif : le langage 
PLASMOID, base de l'interprète expérimental PLASMA (SHROBE 1976) est 
totalement composé de macro-définitions. 

En dehors de LISP, l'utilisation de macros est en général associée 
avec le pré-traitement de textes le plus souvent en langage assembleur, 
préalablement à une phase de traduction qui précédera la phase d'exécution. 
Ce pré-traitement en général expansif est connu sous le nom de macro- 
génération. 

Quelques langages de plus haut niveau, tel que PL/1 permettent, 
au préalable à la compilation, une certaine dose de macro-génération. Le 
traitement du texte à macrogénérer est lui-même spécifié dans un sous- 


ensemble de PL/1. 


L'utilisation des macros est, dans le cadre d'un interprète LISP, 
trés différente : ume macro est définie comme une fonction LISP et le 
traitement spécifié par cette macro peut mettre en jeu toute la puissance 
de l'interpréte, sans restriction. 

Par ailleurs, la macro-génération n'est pas, en LISP, une phase préalable 

à une traduction mais peut intervenir à n'importe quel moment de l'exécution 
d'un programme. 

Dans les interprètes LISP, les macros sont utilisées pour concilier les deux 
buts en général contradictoires : pouvoir expressif et efficience en utili- 


sation mémoire et rapidité de calcul. 
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exemple I 
EVAL, recevant la forme 
(1) CLET (Cvar, exp)... Cvar exp )) corps ) 
1) évalue chacune des exp, ... exp 
2) préserve les valeurs courantes des variables Vi see ve 
3) affecte les valeurs des EXP, ++. exp à ces variables 


4) évalue le corps du LET. 


Ainsi LET crée de nouvelles variables locales, en définit 
la portée, et les initialise. 
Le traitement désiré est équivalent à celui obtenu par 


l'application 
(2) CCLAMBDA (var, ... var,) corps) EXP, -.. EXP, ) 


Mais cette dernière forme permet de surcroît, grâce à la fonction 
SELF des appels récursifs de l'opérateur, ici une lambda-expression 
anonyme. 

LET pourrait être réalisée par une FEXPR ou une FSUBR qui 
stmuleratt la forme (2) à chacune de ses évaluations. 

Il est plus simple et plus efficient de macrogénérer (1) en 

(2). 

La macro-génération n'aura lieu qu'au moment de l'évaluation de 


cette forme LET particulière, et consistera en 
un remplacement physique de (1) en (2) , devenu donc 
définitif 
. l'évaluation de (2) 


Toutes les évaluations ultérieures de cette ex-forme-LET 


seront alors des évaluations de (2). 
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La macro-génération en VLISP comporte deux aspects 


1) double évaluation : 


Soit f une fonction de type EXPR, SUBR, FEXPR, FSUBR ou LEXPR. 


Nous aurons, à l'appel de f 


e expresston 
appel-de-f ——» |EVAL| ———> Desa tat + 


Si f est de type MACRO 


sne expresston expresston | 
i arts es -résultat | Sac eg “résultat z 


Un appel de MACRO induit une double évaluation 


2) liaison des arguments 
Nous la décrivons par trois exemples 
2.1) Soit f définie comme 1'EXPR, avec A.CVAL = 0 
(DE F CX Y) corps) 


A l'appel CF (ADDI A) 2) 


nous aurons les liaisons 


X.CVAL 
Y.CVAL 


1 
2 


2.2) Soit f définie comme la FEXPR 
CDF F (X Y) corps) 


A l'appel (F CADDI A) 2) 


nous aurons les liaisons 


X.CVAL = CCADDI A) 2) 
Y.CVAL = NIL 


Ainsi, à l'appel d'une fonction de type FEXPR(ou FSUBR) le 


premier argument est lié au CDR de L'appel. 


2.3) Soit f définie comme la MACRO 


CDM F (X Y) corps) 


A l'appel (F CADDI A) 2) 


nous aurons les liaisons 


X.CVAL = (F CADDI A) 2) 
Y.CVAL = NIL 


Ainsi, a l'appel d'une fonction de type MACRO, le premier 
(1) 


argument est lié à L'appel lui-même ~’. 


Nous sommes à présent en mesure de réexaminer en détail le 
traitement de la macro LET. En voici la définition VLISP : 
CDM LET CCALL) CRPLACB CALL 
| ~-----~------~~-- (CONS (CONS LAMBDA 
| (CONS CMAPCAR CCADR CALL) 'CAR) 
CCDDR CALL))) 
CMAPCAR CCADR CALL) 'CADR)))) 
La fonction auxiliaire  (RPLACB x y) 


aura comme effet 
CRPLACB € xear . xedr) ( year . yedr)) = C year . yedr) 
i 2 I 


CAR et CDR du premier argument seront remplacés phystquement 


par le CAR et le CDR du second. 
Voici la définition de RPLACB en VLISP : 


(DE RPLACB (X Y) 
CRPLACA X CCAR Y)) 
CRPLACD X CCDR Y))) 


(1) L'inclusion du nom de la macro-fonction dans l'argument de l'appel, et le 
caractére fonettonnel des macros VLISP en apparente le traitement au 
remarquable systéme macro-générateur GPM (STRACHEY 1965). 
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Soit l'appel de macro 
(LET CCX CADDI AD) CY 2)) corps) 
Nous aurons les liaisons et les valeurs 


CALL.CVAL = (LET !- corps) 


CCAR CALL) > LET 
(CADR CALL) > CCX CADDI AD) CY 2)) 
CCDDR CALL) > corps 
et 
CMAPCAR CCADR CALL) 'CAR) > (X Y) 
(MAPCAR CCADR CALL) 'CADR) > CCADDI A) 2) 


L'évaluation de la forme 1 de la macro LET donnera donc 
CCLAMBDA (X Y) corps) CADDI A) 2) 

que RPLACB substituera physiquement comme 
CRPLACB (LET ?-) CCLAMBDA ?-) 2-3) > CCLAMBDA ?-) ?-) 


et CCLAMBDA ?-) ?-) sera passé a EVAL. 


La communauté LISP, dans son jargon spécifique, a donné å ce type de MACRO 

le nom évocateur de «MACROS écrasantesn 

On notera que le traitement effectué par les macros écrasantes peut être trés 
complexe puisqu'il ne sera effectué qu'une seule fois : toutes les évaluations 


ultérieures ne rencontreront que la forme macro-générée. 


a oe oe en té te oe mn 


Dans l'esprit du LET, une forme plus générale que la 
forme LABEL de LISP 1.5,permettant la définition simultanée 


de lambda-expressions récursives, peut être macro-définie 


CLETREC expr 


(nom, lLambda-exp, ) 


(nom Lambda-exp ) 


en 


CCLAMBDA (nom, ... nom ) exp) 
'Lambda-exp, 


'Lambda-exp ) 
La définition de LETREC sera en VLISP 


(DM LETREC CCALL) CRPLACB CALL 
(CONS CLIST LAMBDA 
(MAPCAR CCDDR CALL) 'CAR) 
CCADR CALL.) 
CMAPCAR CCDDR CALL) 
'CLAMBDA (CALL) CLIST QUOTE CCADR CALL))))))) 


L'expression exp sera alors évaluée dans un environnement local 
dans lequel les nom seront liés aux lambda-exp, . Cet environ- 
1 


bane 


nement disparaîtra à la fin de l'évaluation de exp. 


De nouvelles structures de contrôle peuvent être définies en 


VLISP par macro-génération. Voici la structure REPEATWHILE 


CREPEATWHILE e, ... e e-test) 


n 


qui évalue en séquence 2, ... e tant que la valeur de la 
n 
dernière expression e-test est différente de NIL : test en 


fin de séquence. 
Sa macro-définition sera 


(DM REPEATWHILE CCALL) CRPLACB CALL 
(LIST 'WHILE CCONS 'tPROGN (CDR CALL))))) 
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La phase de macro-génération peut naturellement être récursive. 


Voici la macro MCONS 


CMCONS e, ... € ) 
générant 
(CONS e, CCONS e, ... CCONS ee) ... 2) 


(DM MCONS (CALL) 
CAND CCDDDR CALL) 
CRPLACD CALL 
(LIST CCADR CALL) 
(CONS 'MCONS CCDDR CALL))))) 
CRPLACA CALL 'CONS)) 


C MCONS w x y z) sera macro-généré en 

C, CONS w C, MCONS x y z)) et passé a EVAL 

C, CONS w C, CONS x €, MCONS y z))) qui génère 3 

C, CONS w C, CONS x C, CONS y z))) et qui l'évalue. 


6.2.5.2.- Macros d'entrée-sortie 


Les macro-caractéres ont un comportement trés distinct des macros de 
l'évaluateur. De manière plus proche de la macro-génération traditionnelle 
de type PL/1, elles se caractérisent par le passage du mode lecture au mode 
évaluation par interruption. Nous en avons vu, lors de l'étude de MICRO- 
PLASMA, un exemple 


les expressions du type 


Cx, X, ee x J 


étaient à la lecture traduites en 


. x) 


2 n 


CLIST x, x 
grace aux définitions de macro-caractéres 


CMCHAR ] CLAMBDA (©) 'J)) 


CMCHAR [ CLAMBDA ©) CLET CCX 'LIST)) 
CIF CEQ X 1) NIL 
(CONS X (SELF CREAD))))))) 
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Un autre type de macro-caractère très utile (STEELE 1976b) est le double-quote 
(") semblable au macro-caractère quote (') mais tel que dans une expression 
double-quotée, toute sous-expression précédée de (,) est évaluée et substituée 
comme élément, et toute sous-expression précédée de ((1) est évaluée et 


substituée comme segment. 


CMCHAR " CLAMBDA ©) ['DQEVAL [QUOTE CREAD)]])) 
CMCHAR , CLAMBDA ©) CCONS ', CREAD)))) 
CMCHAR @ CLAMBDA ©) CCONS '@ CREAD)))) 


CDE DQEVAL CE) CCOND 
"(ATOM E) E) 
CC= CCAR E) ',) CEVAL CCDR E))) 
CC= CCAAR E) '@) CAPPEND CEVAL (CDAR E)) 
CSELF CCDR E)))) 
CT CCONS (SELF CNEXTL E)) CSELF E))))) 


Ainsi, avec X.CVAL = CF A) 
CEVAL "(LAMBDA (QX B) ,X C)) > CLAMBDA CF A B) CF A) ©) 


Enfin, les macros d'entrée-sortie de type MACIN et MACOUT (définies respecti- 
vement par DMI et DMO) jouent le même rôle que les macro-caractéres, mais 
l'interruption n'est pas provoquée par l'arrivée d'un caractère dans le flot 
d'entrée (resp. de sortie) mais par l'occurence d'un atome en position 


fonctionnelle. 


Ainsi le remplacement uniforme de toutes les formes LET lues par leur 
version macro-générée pourrait être obtenu par 
(DMI LET CLVAR . CORPS) 


"CCLAMBDA ,CMAPCAR LVAR 'CAR) @CORPS) 
@CMAPCAR LVAR 'CADR))) 


A l'appendice 6 nous donnons en VLISP une version des fonctions d'entrée- 
sortie READ et PRINT qui met en évidence le rôle joué par les macros de 


type MACIN et MACOUT. 


TiO oi 


6.2.6.- LES_P-LISTES 


Le type des fonctions standard est déterminé par l'adresse d'implémen- 
tation de leur atome-nom. Celui des fonctions de l'utilisateur est déterminé 


par consultation d'un indicateur sur leur P-liste. 


Les fonctions de consultation et de modification de P-liste sont, en VLISP, 


GET et PUT 


GET =. ° 
subr i — AI<HATOM alors AL.PLIST :: !Al fst 
st Al :: C?- ,A2 !Al ?-) alors 
sinon NIL ::!Al 
fsi 
deree 
he 7 
St A1<HATOM alors 
A1.PLIST :: !A4; 
st Al :: © alors 
(A3 A2) :: !A4.PLIST; derec 
fst 
sinon Al :: 'A4 


fst 

jusqua AY :: €,A3 ?A4) fatre 
A4 :: Cl- ?A4); 
St A4 :: C!-) alors 


(A3 A2) :: !A4.CDR; derec 
sinon A4 :: Cl- ?A4) 
fst 
fjusa 
A2 :: !A4.CAR; derec 


Les fonctions standard DE et DF réalisent la définition de fonctions de type 
EXPR-LEXPR et FEXPR en créant la lambda-expression attachée à l'indicateur de 
type sur la P-liste du nom de la fonction. Voici par exemple l'implémentation 


de DE 


ae i 
AT 2 CIAL 2A29: 


CEXPR LAMBDA : A2) :: C!A3 ?A2); app PUT 
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Toutefois une P-liste, en VLISP peut ne pas être liée à un atome. GET et PUT 


sont définies sur des P-listes autonomes. 


Ainsi (GET 'CA 1 B 2) 'B) = 2 
et (PUT 'CA 1 B 27 "CG 3): = (AL B:2 € 3) 


Cette implémentation des P-listes rend aisée la définition de MEMO-FONCTIONS 
(McCARTHY 1962b, MICHIE 1967, FRIEDMANN 1976c), objets à mi-chemin entre 


procédures et tables consultables. 


Voici par exemple la définition sous forme de mémo-fonction de la fonction 
Fibonacci en VLISP, telle qu'aucun appel de la fonction ne sera calculé plus 
d'une fois, pour toute valeur de l'argument. 
(DE FIB CN) 
COR (GET 'FIB N) 
CCLAMBDA OO CPUT 'FIB X N) X) 
CIF CLT N 22-1 


(PLUS CFIB CSUBI N)) 
(FIB CDIFFER N 2))))))) 


6.2.7.- EXPRESSIONS CONDITIONNELLES, SELECTION PAR CAS ET ITERATIONS 


En VLISP, l'expression conditionnelle de base est 


(IF 230p 6. 6. #60 


2 n 
exp est tout d'abord évaluée; si la valeur retournée est non-NIL, la valeur 
de IF sera celle de e,, qui est passée directement a EVAL , @, ... e étant 
n 


ignorés. Si, en revanche, la valeur de exp est NIL, œe .. @ sont évalués 
n 


2 


en séquence par PROGN et la valeur IF sera celle de e 


Cette forme très simple d'expression conditionnelle n'existe qu'en VLISP. Elle 

est d'un emploi excessivement fréquent dans l'écriture de procédures récursives 
où elle se substitue avantageusement au COND peu lisible dans les cas simples. 
Cette construction est d'une grande utilité, tant pédagogique que pratique. 


Son absence dans les autres versions de LISP est une source d'inconfort certain. 
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Voici l'implémentation de IF 


IF = 
Fsubr cay A1 : P) :: CCIAL ?-) ?P); ree EVAL; 
St Ab :: © alors P tt CC!- !- RAT) ?P); app PROGN 
stnon Pot: CCt- !Al ?-) ?P); app EVAL 
fest 


SE €, +++ € sont omis, l'évaluation du IF «passe au travers de ses parentheses» 


et retourne NIL. 


Le COND de LISP 1.5 a été étendu, sous la forme oe 


CCOND C Go +. C ) 


n 


dans laquelle chaque clause €, est de la forme 


Ce Css. e ) 


le premier élément e de la clause C est évalué, et, si la valeur retournée 
est non-NIL, les e, +e de la clause sont évalués en séquence, et la valeur 
‘de e est retournée comme valeur du COND. Si toutefois l'évaluation de e, 
livre NIL, la clause € est traitée de la même façon. Si aucune des clauses 
n'est retenue, la valeur du COND est NIL. Une clause ce. peut être réduite 


a l'unique élément Ce ), et si son évaluation livre non-NIL, cette valeur 


est retenue comme valeur du COND. 
Voici l'implémentation de COND 


COND ubr j . 
tantque (Al Al : P) :: CCC!A1 ?-) ?-) ?P) farre 
ree EVAL; P :: C!A2 ?P); 
st Al :: NIL alors A2 :: C!- ?A1) 
. gtnon A2 :: CC!- ?A2) ?-); 


81 A2 :: NIL alors derece 
sinon A2 :: !Al; app PROGN 
fer 
Fst 
ftan 
derec 


(1) Cette extension du CONDest due à Daniel G- BOBROW (BOBRÓW 1969). 
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En VLISP, les fonctions AND et OR sont des structures de contrôle et retournent, 
dans le cas du AND, NIL ou la valeur du dernier argument, et dans le cas du OR, 
NIL ou la valeur du premier argument tel que son évaluation retourne non-NIL. 
AND et OR sont ainsi utilisables pour construire des COND miniatures 

CAND e, e,) et COR e, e,) seront respectivement équivalents à (COND Ce, e,)) 

et a CCOND Ce,) Ce,)). L'implémentation de OR et AND VLISP leur permet d'être 


utilisés dans les appels récursifs interprétés itérativement. 


AND fe ube j 
tantque (Al Al : P) :: CCIAL !- ?-) ?P) fatre 
ree EVAL; CAL : P) :: C!A2 C!- ?A1) ?P); 
st A2 :: O alors derec fst 
ftan 
Al :: C'A1); app EVAL 
OR sbi 7 


tantque (Al Al : P) :: CCIAL !- ?-) ?P) fatre 

ree EVAL; P :: CC!- ?A2) ?P); 

st Al :: ©) alors A2 :: !Al sinon derec fst 
ftan 
Al :: CIAL); app EVAL 


La fonction de sélection par cas SELECTQ a été étendue, sous la forme 


CSELECIO ESC Ca as 69 


n 
où e est une expression LISP évaluable et chaque clause C, ..., @ est 


de la forme 
(atome suite-des-expressions-à-évaluer) 


L'expression € est évaluée, puis comparée à l'atome de chacune des clauses 
Gio tery Ge S'il y a identité, la valeur du SELECTQ est celle de la sutte- 


des-expresstons correspondante. S'il n'y a identité pour aucune, la derniére 


clause ec est évaluée par PROGN. 
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SELECT ee 
Résubr CAL Al : P) :: CCIA1. SE) 2P); 
rec EVAL; P :: CC!- 7A2) ?P); 
tanique A2 :: C!A3 !- ?-) fatre 
st A3 22 GAIL ?A1) alors 
app PRCGN 
fst i 


A2 :: Cl- ?A2) 
ftan 
A2 :: C!'A1); app PROGN 


Plusieurs formes d'itérations sont implémentées, en particulier la fonction 


(WHILE e, see €.) 


n 
qui évalue séquentiellement les e, ... @ tant que l'évaluation de e, retourne 
n 
la valeur non-NIL 
Wr I Le = 


Fsubr CAL: P) it IP; 


repeter P :: CC!IAl ?-); rec EVAL; 
St Al :: NIL alors P :: Cl- ?P); 
sinon P it ((!- 2A1) 2-); ree PROGN 
fst 

frep 


Les fonctions de type MAPC fournissent une autre forme d'itération dans 
laquelle une fonction f , second argument du MAPC est appliquée de gauche 


à droite à chaque élément d'une liste, premier argument du MAPC 
CMAPC !e !fonetton) 


la fonction argument f peut être une fonction standard, une fonction définie 


par l'utilisateur, ou encore une lambda-expression. 


MAPC = 


out af Al :: ©) alors 
sinon (A2 : P) :: IP; 
|] = tantque (Al AI : P) :: CCIA4 ?-) ?P) fatre 
CCAG : NIL) : P) :: CAL !- IAL ?-); 
ree APPLY; P :: CC!- ?A1) ?P) 
fla 
Poi: Cl- ?P) 


fst 


derec 
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MAPC donne accès aux éléments e, ... e, de la liste-argument, en appliquant 


successivement 


Cf e ) CE SB ee Mee) 


Pour avoir accès à la liste-argument elle-même, i.e. à chacun de ses 


successifs, la fonction MAP réalisera 
CE CCDR’ e)) CE CCDRÍ e)) ... COR" e)) 


Son implémentation sera identique à MAPC, à l'exception de la ligne | qui 


sera changée en 
|' =-=- tantque (Al Al : P) :: C!A4 ?P) faire 


La fonction MAPCAR sera utilisée pour conserver dans une autre liste les 


résultats des applications successives réalisées par MAPC. 


MAPCAR pourrait s'exprimer en VLISP comme 


CDE MAPCAR CL F) 
CIF CNULL L) NIL 
(CONS CF CNEXTL L)) CSELF L FDDD) 


et a le même schéma qu'EVLIS (cf. §6.2.1). 


La technique d'implémentation par accrochages successifs de bords droits 


sera ici également utilisée 


MAPCAR = 
or St Al :: © alors 
sinon (NIL : NIL) :: !A3; CA2 A3 : P) i: IP; 
tantque (Al Al A3 : P) :: CC!AH ?-) ?P) fatre 
CCA4 : NIL) : P) :: CIA2 !- !- AL ?-); 
noe: APPLY; 
CCAL : NIL) : P) :: CIAL C!- 2?A2) !A3 ?P); 
CA2 Al Al) :: CIAL !A3.CDR !A3) 
ftan 
P :: Cl- (!- ?A1) ?P) 
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6.2.8.- LE PROBLEME DES PROGS 


ee ee eed a ee ee ee ee ee ee Gale APE Mu (uit D DEN mp 


PROG et ses fonctions associées, RETURN et GO, survivances en LISP 
de la «programmation de type FORTRAN» (McCARTHY 1960a) sont implémentés en 
VLISP essentiellement pour conserver la compatibilité avec d'autres versions 
de LISP. C'est probablement l'emploi du PROG qui a été à la source des critiques 


les plus justifiées adressées à l'usage de LISP sous interprète 
8 


1) inefficience due au balayage du corps de fonction à la 
recherche des étiquettes, balayage renouvelé à chaque 
appel du prog! 1” 

2) encombrement de la zone des listes, en LISP 1.5, par les tables 
de symboles ainsi constituées, encombrement également redoublé 
à chaque appel. Ce défaut reste présent dans une moindre mesure 
en LISP 1.6. (QUAM 1972) lorsque ces tables de symboles sont 
implantées dans la pile de controle 

3) inefficience des branchements de type (GO etiquette), inévita- 
blement précédés d'une recherche de l'étiquette dans la table 
des symboles 


4) impossibilité d'effectuer des RETURN multiples (CLINT et HOARE 


1972) ,i.e. de faire communiquer des PROGS dynamiquement 


imbriqués. 


Pour toutes ces raisons, l'utilisation de LISP sur mini-ordinateurs est 
incompatible avec l'usage des PROGS, la lenteur d'exécution et l'encombrement 
que leur usage implique interdisant l'introduction et l'évaluation de 


programmes LISP non-triviaux dans des ressources limitées. 


(1) la possibilité d'une inclusion d'une forme PROG dans le corps d'une 
fonction récursive rendrait très lourde à l'interprétation l'implémentation 
de ce balayage comme une mémo-fonction i.e. de n'effectuer la recherche 
des étiquettes qu'au premier appel d'un PROG, la table des symboles ainsi 
constituée restant consultable lors des appels suivants. 
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L'unique et considérable intérét des formes de type PROG réside dans la 
fonction RETURN, donnant la possibilité de sortir d'un bloc à partir d'un 
de ses points quelconques, retour accompagné d'une valeur, celle-ci se 
donnant alors pour la valeur de l'appel du PROG. Toutefois, la fonction 
RETURN ne permettait d'effectuer qu'un retour à la fonction directement 
appelante du PROG dans laquelle elle était dynamiquement incluse, et ne 
permettait pas un retour à un niveau appelant quelconque. 

C'est à ces difficultés que tente de porter remède l'introduction de la 


fonction ESCAPE en VLISP que nous examinerons plus loin. 


Voici en VLISP, l'implémentation de PROG 


PROG 


fsubr CAL NIL PLOC PETIQ : P) :: CCIX 2A1) 1X ?P); 
app LIER} CP Al) 2: CIPLOC 1A2); 
tantque A2 :: C!X ?A2) fatre 
St X<HATOM alors (X A2 : P) :: [P fat 
ftan 
| CP Al) :: CIPETIQ !A2); 
PROG2 = tantque A2 :: (IX 2A2) fatre 
st X<HATOM alors 
sinon (X A2 : P) :: CIAL ?P); 
rec EVAL ; P :: CA2 ?P) 
far 
fhan 
PLOC :: IP; azp DELIER; P :: CIPLOC !PETIQ ?P); 
rec ` 
RETURN 2 
eel USSR EIEN SE LOC fe EEIN LE TRS eo DEL TER ee 
PLOC :: IP; ap CELIER; P i: CIPLOC !PETIQ ?P); 
derese 


La fonction de type SUBR (GOTO e) permet de ne pas spécifier ā l'avance 
l'étiquette de branchement, mais de considérer celle-ci comme le résultat 
de l'évaluation de la forme e. Cette fonction permet de lever l'ambiguïté 
inhérente au GO de MACLISP (WHITE 1970), où l'expression e est considérée 
comme une étiquette si e est un atome, et comme une expression à évaluer 


devant ramener une étiquette si e est non-atomique. 
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Dans la pratique, GO et GOTO jouent le rôle d'appel de fonction de leurs 
arguments, qui ne seraient jamais suivis de retour à l'appelant et dont 
la principale faiblesse est de ne transmettre aucun message à l'appelé. 
Comme nous le verrons au $7.1, les appels post-récursifs sont exécutés en 


VLISP comme des branchements capables de transmettre des messages. 


SO poy = Al i: CIAL); app GOTO 
GOTO. 


UOT 


it 


Notre implémentation du PROG est proche de celle de LISP 1.6, les tables 
d'étiquettes étant implémentées, en VLISP T1600, dans la zone de contrôle, 
repérées par le pointeur PETIQ. PLOC est un pointeur sur le vecteur de 
liaison des variables locales du PROG. Ce pointeur, repérant la même sous- 
zone de contrôle que LLIEN, lorsque la forme évaluée est statiquement 
incluse dans le corps du PROG, devient nécessaire lorsqu'un (GO !etiquette) 


est évalué dans le corps d'une fonction appelée par le PROG 


(DE FOO C...) ... CGO E) ...) 
(PROG C...) ... (FOO ...) ... E Coe.) ...) 


6.2.9.- LA FONCTION ESCAPE 


La fonction ESCAPE est la fonction de saut la plus puissante compatible 
avec la structure de contrôle récursive de LISP. Elle n'existe avec cette 


généralité qu'en VLISP. 


eq AL er AI SS A eA © Qu ge rm à 


Elle se présente sous la forme 


(ESCAPE f Ce. En D 


Le 


ou €, ... en est une suite d'expressions à évaluer, et f est un atome 
choisi par l'utilisateur, qui, dans la portée du bloc-ESCAPE, acquiert le 


statut de fonction de sortie de bioc, ou fonction d'échappement. 
> 


ESCAPE évalue. les e, ses €y en séquence et 


1) si dans la portée du bloc-ESCAPE, est demandée l'évaluation 
de (E ob, ... obm) les ob, ... obm seront évalués en 
séquence, et on sort du bloc-ESCAPE «en chute libre» selon 
la jolie expression de (CARPENTIER 1976), en ramenant la 


valeur de ob, 


2) si aucune forme de type (f ...) n'est évaluée, la valeur 
du ESCAPE sera alors celie de eo: 
Bien entendu, toutes les variables ayant pu être liées dans la portée du 


bloc-ESCAPE, seront restituées avec leur valeur antérieure. 


exemple I 
CESCAPE AS 
E 


SEZ 
(WHILE L CAND CLT CNEXTL L) 9) CASSEZ L)))) 


Cette forme recherche dans la liste L un segment dont le CAR soit négatif. 


Sl ce segment est obtenu, L devient un pointeur sur ie CDR de ce segment, 


dans le cas contraire la valeur de la forme est NIL. 


exemple 2 


(DE COPY-IF-P CE P) 
CESCAPE NO-P 
CCOPY-IF-P-2 EDD) 


CDE COPY-IF-P-2 (E) 
CIF CATOM E) CIF CP ED E 
(NO-P (LIST 'NOT E))) 
(CONS CCOPY-IF-P-2 (NEXTL ED) 
(COPY-IF-P-2 E)))) 


- eo mo EE eee 


La fonction COPY-IF-P livre une copie de l'expression E si tous les atomes 
ayant des occurences dans E satisfont à la condition P, et si ce n'est pas 


le eas livre une liste de la forme 


(NOT atome-ne-satisfaisant-pas-la-condition) 


Apparentée à l'opérateur J de LANDEN (LANDIN 1965, REYNOLDS 1972), la fonction 
ESCAPE permet de sortir de tout bloc-ESCAPE quelque sott la profondeur 
d'imbrication dynamique de l'appel de la fonction de sortie. Elle permet 

ainsi d'éviter l'usage des PROGS, tout en conservant la notion de branchement- 


de-retour (CLINT et HOARE 1972), en fonctionnalisant la notion d'étiquette. 


Elle a de surcroît l'avantage 


1) d'être indépendante du type de bloc (WHILE, MAP, PROG, 
À-expression, etc.) dans lequel la fonction de sortie est 


(1) 


évaluée . Ainsi les propriétés de la fonction ESCAPE 
seront conservées quelques soient les extensions de 
structures de contrôle qui pourront être incorporées à 
VLISP | 

2) de mettre en évidence ce fait que la programmation sans 
branchement n'implique pas pour autant l'abandon des étiquettes 
(1a fonction de sortie de ESCAPE est une étiquette) 

3) de ne pas exiger de l'utilisateur d'avoir à prévoir le nombre 
d'imbrications statiques ou dynamiques à franchir pour sortir 
du bloc-ESCAPE(ce qui est une contrainte insupportable si le 
langage est interprété, et n'offre pas de difficultés insur- 
montables si le langage est compilé) 

4) de permettre une implémentation trēs aisée, dans une extension 
de LISP telle que CONNIVER, des fonctions de sortie de type 
ADIEU (McDERMOTT 1974) 

5) d'autoriser des imbrications arbitrairement complexes de blocs- 
ESCAPE, chacun des blocs imbriqués pouvant appeler la fonction 


de.sortie d'un bloc imbriquant quelconque. 


(1) par opposition aux solutions proposées en BLISS (WULF 1971) dans lequel 
chaque structure de contrôle définit sa fonction de sortie particulière 
(EXITLOOP, EXITBLOCK, EXITCOND, etc.) faute d'étiquettes. 
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La construction ESCAPE est plus puissante que la fonction de saut CATCH de 


MACLISP (MOON 1974). Nous en montrerons les raisons au §6.3. 


Voici l'implémentation de ESCAPE 


tl 


ESCAPE 


fsubr 
Al :: CIF ?2A1); 
? =, j Per 
(ESC F PACA eaor e LLEN PLOC PETIG A PS i CUr SER. SP). 
POS BEDE. poe PRCC 
app DELIER; P :: C!PLCC ETIO ees 
derece 
ESC 
fsubr eee se i 
CVARESC : P) :: IP; moe PROGI 
CPLETEM) 2% ICCIVARESC 22) 15); 
a mn ER ae. + « a AM ~ a) - k | ad 
Jusqua P 1? C,VARESC ?-) fatve app CELIER “usa 
app DELIER; Po :: C'PLOC !PETIQ ?P); 
rec 


La construction LESCAPE est une restriction de ESCAPE à la chute libre hors 


des lambda-expressions. 
L'appel 


n 


(LE SCAPE és 60 


évalue les e +++ e, en séquence, et sort, en ramenant la valeur de e , 
de la lambda-expression qui a été la plus récemment appliquée. Elle permet, 


de même que ESCAPE, d'éviter l'usage des RETURN et donc des blocs PROG. 


exemple 
CLET “COX. LD 
(WHILE X CAND CLT CNEXTL X) 9) CLESCAPE X)))) 
raméne le premier CDR de L précédé d'un nombre négatif, sinon 


NIL 
Voici l'implémentation de LESCAPE 


LESCAPE | _ Ti 
j ree PROGN; 


LLIEN :: !P; app DELIER; derec 
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La construction SELF est une contribution de VLLSP a l'évaluation de 
procédures récursives en LISP. 


L'idée en est fort simple : pour toute fonction 
CLAMBDA Cu, ... vd corps) 
l'occurence de l'appel 


(SELF A +... 4 ) 


n 


au cours de l'évaluation de corps sera traité comme un appel récurstf 


de cette lambda-expression. 


Donc 


(LAMBDA (v) ?- (SELF a) ?-) 


Le 


est équivalente en terme de P-EVAL a 
(fie GC C2) CA WG) 2+ C a) 2-92) 
VLISP étant un P-évaluateur, fix sera l'opérateur YV du §3.5.1 


fix = O Cy) Ca a)) 


ji 


et a = A Cx) Cy O Cz) CG x) z)))) 

On notera une curieuse complémentarité entre SELF et LESCAPE : LESCAPE 
quitte,en retournant un message, la lambda-expression la plus récemment 
appliquée, SELF réapplique, en passant un message, la lambda-expression 

la plus récemment appliquée. 

En utilisant la terminologie de LISP 1.5, toute lambda-expression est en 
VLISP l'évalué implicite d'une forme LABEL, et est ainsi capable de se 
rappeler récursivement. 

Complémentarité, de méme, avec le traitement des variables : un appel de 
SELF est fluide, en ne se rapportant qu'a la plus récente lambda-expression 


appliquée. 


Un tri récursif par insertion sera défini ainsi avec SELF 


CDE TRIER CL) 
| ------ CAND L CLET CCX CCAR L)) CL CSELF CCDR L)))) 
CIF COR (NULL L) CLE X CCAR L))) CCONS X L) 
D aa CCONS CCAR L) (SELF X (CDR LODD 


L'appel de SELF à la ligne | se rapporte à TRIER, l'appel de 
la ligne 2 se rapporte à la fonction anonyme d'insertion 


définie par LET. 


L'introduction en VLISP de la construction SELF permet 


1) une clarification pédagogique : il est très naturel de s'envoyer 
un message 4 soi-même 

2) de traiter récursivement des lambda-expressions anonymes, y compris 
celles définies implicitement par LET | 

3) de ne pas passer inutilement,lors d'un appel récursif, des arguments 


qui ne seront pas modifiés, tout en les conservant locaux 


exemple 2 : 


La concaténation d'une copie de la liste X à la liste Y serait 


CDE APPEND (X Y) CLET CCX X)) 
CIF X CCONS CNEXTL X) CSELF X)) 
Y))) 


L'argument Y de APPEND a été éliminé de la récursion, en restant 


local. 


4) d'utiliser naturellement en style récursif une forme très fréquente 


de programme 
(DE FOO !- ?intttaltsattions ?boucle) 


qui était en LISP 1.5 le motif de la conservation de la forme LABEL. 
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exemple 3 : 


La fonction C-REVERSE inverse la liste circulaire L 


(DE C-REVERSE CL) 


initialisations ------ CAND L 
(LET CCCOUR (CDR L)) CPRED L)) 
itération ------------------ CIF CNEQ L COUR) (SELF (CDR COUR) CRPLACD COUR PRED)) 
CRPLACD L PRED) | 
PRED)))) 


La construction SELF est naturellement compatible avec ESCAPE, ainsi qu'avec 


l'exécution itérative d'appels récursifs (cf. §7.4.1). 


exemple 4 : 


L'exemple 2 du §6.2.9 peut se reformuler 


(DE COPY-IF-P CE P) 
CESCAPE EXIT 
(LET CCE E)) 
CIF (ATOM E) CIF (PE E 
CEXIT CLIST 'NOT E))) 
(CONS (SELF CNEXTL ED) (SELF E)))))) 


SELF permet d'obtenir trés facilement en VLISP, la construction DO de MACLISP : 


sachant que la forme DO 


(DO CCvar, init, pas,) ... Car, init, Pas, D) 
(test-fin corps-fin) 
corps-sut te ) 


est équivalente à 


CLET CCvar, init, >) ... Car, tntt,)) 
CIF test-fin CPROGN corps-fin) 
corps-sutte 
(SELF pas, ... pasn))) 


Si les appels post-récursifs sont exécutés itérativement, DO pourra être 


systématiquement macro-généré par la macro donnée à l'appendice 7. 


PP a ii yy pep pl PQ OP om a 


Voici l'implémentation de SELF 


SELF Le = 
P :: C?- APPLY3 !Al ?-); app APPLY 


Enfin, l'utilisation de SELF permet de rendre les fonctions totalement 


tndépendantes de leurs noms 


CSETO-F "Che. CX) waar CP a) ae: 2D 
GOs. OD, pee (CG. DD tea: 2) 


Les fonctions À, et À, sont liées à leurs noms F et G sur 

leur’ C.valeur : F.CVAL = À, et G.CVAL = },. 

En cas d'échange des C.valeurs de F et G, on aura F.CVAL = }, 
et G.CVAL = À, . Les appels (F a) et (G b) seront alors respec- 
tivement interprétés comme appels de À, et à. Cette anomalie 
se produirait de la même façon si À, et À, étaient liées sur 
les P-listes de F et G, en cas d'échange de celles-ci. 

Cette anomalie ne se produit plus si À, et À, sont définies 


avec SELF 


CSETO TON 100: awe COBLP AD. so, 1) 
GG CYF ss ÉSERF 23659) 


Dans ce cas À, et À, sont devenues totalement indépendantes de 


2 
leur support : C.valeur ou P.liste d'atome-nom. Ainsi la défini- 
tion de fonctions récursives n'est plus dépendante des modifica- 


tions d'états d'un contexte global. 
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6.2.11.- LE PROBLEME DU FUNARG EN VLISP LA 


eee 


FONCTION CLOSURE 


ma mr eee eee ee ee ee ee eee ee ee ee dote 


La fonction CLOSURE constitue une solution au probléme du FUNARG 


(cf. §3.6) 


permet, dans l'environnement fluide de VLISP, 


d'arguments fonctionnels. 


Un appel de CLOSURE aura la forme 


conséquence de la nature de P-évaluateur de VLISP. CLOSURE 


le traitement de valeurs et 


(CLOSURE liste-de-vartables exp) 


où exp est une lambda-expression 
CLAMBDA Cx, ... Ln) corps) 


et liste de variables = 


W, 


+ e è 


v2 


est une liste de variables ayant des occurences libres dans exp. 


Un appel de CLOSURE retourne une fermeture c 
appliquée, les valeurs des variables v, ... 
variables au moment de la constructton de la 
de l'application de €. 

Cette solution est en lecture-seule : si les 
affectées a de nouvelles valeurs dans corps, 


ignorées lors de la prochaine application de 


de exp, telle que si € est 


v, seront les liaisons de ces 


fermeture, et non au moment 


variables Di see DV sont 


n 


ces nouvelles valeurs seront 


la fermeture c. 


La solution est en lecture-écriture si la sortie de la lambda-expression 


clôturée exp est effectuée par un appel de la fonction CESCAPE 


CCESCAPE e, é, 2 


qui évalue les e ... e, 


et sort de exp en retournant la valeur de e 


Dans ce cas les nouvelles valeurs éventuellement affectées a Vive 


p" 


en séquence dans l'environnement de la fermeture 


D, 


seront retrouvées lors de la prochaine application de la fermeture. 
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CDE DOUBLE CF) 
(CLOSURE CF) 
CLAMBDA (X) CF CF X))))) 
L'appel (DOUBLE une-fonetion-f) retourne une fermeture qui, 
appliquée à un argument, appliquera deux fois f 4 cet 


argument. 


exemple_2 : 


(DE COMPTEUR ©) 
CLET CCK 0)) 
(CLOSURE (CK) 
(LAMBDA (MSG) CCESCAPE (SETQ K 
CIF C= MSG 'RAZ) 9 CADDI K)))))))) 


Un appel CCOMPTEUR) retourne une fermeture qui compte et 


retourne le nombre n de fois ot elle est appliquée. 


Ca) >n 


Ce 'RAZ) > 9 


Si elle est appliquée à NIL, ce raméne n , si elle est 


appliquée à l'argument RAZ, le compteur est remis à 0. 


La fonction PREMIERS retourne une fermeture c telle que 


Ce TOUS) > la liste des nombres premiers déjà calculée 
Ce DERNIER) > le dernier nombre premier calculé 


Ce) > le nombre premier suivant 


De même que dans l'exemple précédent, un nombre quelconque 


de fermetures construites par PREMIERS peuvent être actives 


simultanément et appliquées de façon indépendante. 


(DE PREMIERS © 
CLET CCP (LIST 2 3)) (DP 30 
(CLOSURE (P DP) CLAMBDA (MSG) CSELECTQ MSG 

(TOUS P) 

(DERNIER DP) 

((NCONCI P 

(SETQ DP CLET CCK CCDR P)) CN (+ DP 2))) CCOND 

(C= CREM N CCAR K)) 0) (SELF CCDR P) (+ N 2))) 
(CLE (QUO N CCAR K)) CCAR KD) ND 
(CT (SELF CCDR K) N)))))) 

(CESCAPE DP))))))) 


Nous avons examiné au §3.6 les difficultés liées au probleme du FUNARG dans 
les P-évaluateurs. Le probléme est résolu en VLISP par la construction par 
CLOSURE d'un environnement privé à la fermeture, limité aux variables libres 


spécifiées dans l'appel de CLOSURE (1), 


La fonction CLOSURE est apparentée à l'application partielle en POP 2 
(BURSTALL 1971) dans laquelle une procédure appelée en mode «gelé» avec un 
nombre incomplet diarenn s produit une fermeture de cette procédure 
pour l'application partielle. Nous avons adopté en VLISP une solution plus 
souple : n'importe quelle variable de l'environnement actif au moment de la 


constitution de la fermeture peut être spécifiée dans l'appel de CLOSURE. 


Le principe de l'implémentation de CLOSURE consiste, lors de l'appel 
(CLOSURE Cv, ... Vn) CLAMBDA (x, +.. Lm) corps)) 
A construire et retourner l'expression 
CLAMBDA Cx, ... 2m Vy +++ Un) 
CSETQQ V, Valy +. Un Valm) 


corps ) 


où les val, sont les valeurs courantes des variables vV; au moment de 


l'appel de CLOSURE. 


(1) contrairement à la solution adoptée en LISP 1.5, dans laquelle la fonetion 
FUNCTION liait tout l'environnement en bloc (la A-liste) dans la fermeture. 


(2) plus précisément un segment terminal de la liste d'arguments. 


On observera que 


1) est utilisée la possibilité mentionnée au $6.2.4 d'appliquer 
des fonctions 4 des arguments en nombre inférieur 4 celui de 
la définition. Les variables U «++ VU, Sont devenues liées 
leur valeur extérieure à l'appel sera ainsi automatiquement 


préservée et restituée par l'interprète 


2) les liaisons de vV, ... Un ont priorité sur celles des arguments 


TX, +. Xm au Cas où un x serait identique à un v, 


oo, 


3) notre solution est relativement cotiteuse å l'application de 
CLOSURE mais assure une exécution rapide lors de 1'application 
de la fermeture une fois construite : elle est donc bien 
adaptée aux cas dans lesquels les fermetures seront souvent 
appliquées mais pas souvent construites, et inadaptée dans le 
cas contraire. Ce dilemme est inhérent à la nature de P-évaluateur 
de VLISP. Une solution pourrait être un type supplémentaire de 
construction de fermetures : cette multiplication des entités 
nous paraît vaine dans le cas de Lisp 7”. Des solutions plus 


générales devront être trouvées dans de nouveaux langages, dont 


les systèmes de type ACTEURS sont la préfiguration. 


~ 


L'implémentation de CESCAPE est identique a LESCAPE, mais de surcroit remplacera 
physiquement les valeurs val, par les valeurs courantes des vV; dans la portée 


de la fermeture. 


Ces liaisons seront donc retrouvées lors de la prochaine application de la 


fermeture. 


CLOSURE br = 
Al :: C!A2 (LAMBDA !AI ?A3)); 
(A3 A2 : P) :: !P; rec APPEND; 
(NIL : P) :: C!A4 !A3 !A2 ?P): 
tantque A2 :: C!X ?A2) fatre 


CX X.CVAL : A4) :: IAL 
ftan 
("LAMBDA AI C'SETQQ : A4) : A3) :: IAL; 
derec 


(1) «Entta non sunt multiplicanda praeter necessitatem» 
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CESCAPE <- ubr = 
rec PROGN; P :: (?- APPLY3 (LAMBDA !- CSETQQ ?A2) ?-) ?-); 
tantque A2 :: C!A3 ?A4) fatre 
(A3.CVAL : A4) :: CIA4.CAR !- ?A2) 
ftan 
LLIEN. <2. IPS App DELIER; 
derec 


6.2.12.- LE PROBLEME DES VALEURS MULTIPLES : UNE SOLUTION PAR MODIFICATION DE 
EVLIS 


Nous savons que LISP autorise les fonctions 4 nombre variable 
d'arguments, de type LEXPR et LSUBR. 
Beaucoup d'algorithmes calculent de fait plusieurs résultats : un calcul 
de quotient livre également un reste, un calcul de variance donne également 
une moyenne. Il peut donc être souhaitable de faire retourner à une fonction 


un nombre variable de résultats. 


Soit la fonction £f définie à quatre arguments 
(DE £ CW X Y Z) ?-) 

et un appel 
C£ a Cg ?-) d) 


le caractère récursif de LISP implique que l'appel de la 
fonction g se résoudra en un retour à la position de 


l'appel d'un résultat unique a. Nous avons alors les 


liaisons 
W X Y Z 
t } t t 
a Q d NIL 
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Cependant, si g peut ramener deux résultats, i.e. a=a 


nous obtiendrons les liaisons correctes 


W X Y Z 
t q t t 
a Q œ d 


Dans le cadre de LISP, les deux solutions classiques au problème des valeurs 


multiples sont 


1) d'affecter les résultats à des variables globales qui seront 


consultées par l'appelant, ce qui conduit dans le cas récursif, 


a des programmes trés obscurs 


2) de faire construire à l'appelé une 
PP 


liste de ces résultats 


charge laissée à l'appelant de sélectionner les éléments par 


décompositions en CAR-CDR. 


Les inconvénients de ces traitements sont manifestes : diverses solutions 


alternatives ont été formulées. 


Le langage POP 2 (BURSTALL 1971) donne la possibilité de résultats multiples, 


par l'introduction de fonctions de type vartresult 
est laissé en sortie de la fonction sur la pile de 
excellente dans le cadre de POP 2,n'est pas viable 


actuels des fonctions ne sont pas préparés dans sa 


Une autre solution, suggérée par (FRIEDMAN 1976a) 
et (SAMET 1975) pour LISP 1.6 est de considérer le 


s comme un n-uple d'expressions évaluables en n 


s = (LAMBDA !- e, e ... e) 


n 


CS 2e) 9° et Ly 68 wax ALY, 


Ces n résultats sont, au retour de l'appel de 3 
, PP 


de l'appelant de 5. 


un n-uple de résultats 
POP 2. Cette solution, 
en VLISP, où les arguments 


pile de récursion. 
dans le cadre de LISP 1.5 


corps d'une lambda-expression 


résultats 


distribués dans les paramètres 


Cette méthode, compatible avec LISP 1.5 et LISP 1.6 est incompatible avec le 


PROGN implicite du corps des lambda-expressions en VLISP, INTERLISP et MACLISP. 
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STEELE (1976b) propose une construction 


iy, of, «++ ram 
dans laquelle le nombre des résultats est explicitement indiqué. 
Cette solution nous paraît totalement inadéquate, le problème n'étant pas 
de connaître le nombre des résultats, mais bien plutôt de les distribuer 


correctement en arguments de la fonction appelante. 


Une solution partielle serait, en VLISP, de tirer parti du fait qu'un appel 


explicite de APPLY 
CAPPLY 'CLAMBDA (æ, ... £) corps) arg) 


avec arg = Ce, s.. en? 


liera chaque x avec l' e; correspondant. Cette solution est très limitée, 


ne pouvant traiter les cas de 
CCONS Cg ?-)) 


En effet, si g retourne deux résultats a et œ 1ls ne seront pas 


livrés successivement à CONS sous la forme 
CCONS a, a, ) 
mais sous la forme incorrecte 
(CONS Ca, et a, )) 
l'effet correct ne peut être obtenu que par l'appel explicite 


CAPPLY 'CONS Cg ?-)) 


Nous proposons au probléme des valeurs muliples deux solutions complémentaires 
dans le cadre de VLISP : les GAMMA-expressions et la fonction MULTIPLE. Ces 
deux solutions évitent les inconvénients des affectations globales, et la 


décomposition d'une liste par l'appelant. 


LES GAMMA-EXPRESSIONS 


Nous avons introduit en VLISP la classe des GAMMA-expressions 
(GAMMA (x, ... Xn) corps) 
Lorsqu'une GAMMA-expression est appliquée à un argument, cet argument est 


évalué, le résultat de cette évaluation étant une liste, 


i . En ) 


et les x sont liés aux œ; , avant l'évaluation du corps de l'expression. 
Le traitement des GAMMA-expressions est assuré par une modification très 


simple de l'implémentation de APPLY 


CCGAMMA (X Y) corps) (LIST 3 4)) 


les liaisons seront : X.CVAL 


Y.CVAL 


i 
£ 


LA FONCTION MULTIPLE 


CMUETTPEE 6 «es: ØR) 


Si elle est évaluée, les e; seront évalués , et leurs valeurs seront 


distribuées de gauche å droite dans les paramétres de 1'appelant. 


te Orie She me > i dans RS 


CCLAMBDA (X Y) corps) (MULTIPLE 3 4)) 


les liaisons seront : X.CVAL 
Y,CVAL 


li 
+ 
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es ve — ue e pue 


Soit la fonction 
(DE G CX Y) CMULTIPLE X X Y)) 
alors 


(PLUS 2 CG 3 4) 5) > 17 


Cet effet est obtenu par une modification également très simple de l'implémen- 


tation de EVLIS. 


On notera que l'évaluation de MULTIPLE «enlève les parenthèses » : 
HIS CMOLTIPLE à sas ADD e 


et s'apparente en VLISP à l'opérateur UNPACK de PLASMA. 


Les GAMMA-expressions et la fonction MULTIPLE sont complémentaires 


1) dans le cas des GAMMA-expressions, la réception de résultats 
multiples est sousla responsabilité de l'appelant, ou receveur 
2) dans le cas de MULTIPLE, la transmission de résultats multiples 
est sous la responsabilité de l'appelé ou transmetteur. 
Le méme transmetteur peut aussi, selon le cas (IF, COND) envoyer 
un résultat simple ou multiple sans faire d'hypothéses sur le 


nombre de paramétres formels du receveur. 


exemple 5 : 


Calcul de la fonction Fibonacci en temps linéaire 


(DE FIB CN) 
CIF CLT N 2) 1 
(+ (G C- N 2))))) 


(DE G CN) 
CIF C= N 0) CMULTIPLE 1 1) 
| ---------- (LET CCU V CSELF C- N 1)))) 


CMULTIPLE (+ U vV) U)))) 
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On observera qu'ä la ligne |! 
CEE CON SELE PE) 25) 
doit @tre macro-générée en 
CCLAMBDA CU V) 2-) CSELF 2-)) 


La macro LET supportant les valeurs multiples est donnée à 


l'appendice 8 ; elle-même utilise la fonction MULTIPLE. 


Cet exemple, emprunté à (FRIEDMANN 1976a), utilise les 
GAMMA-fonctions. 


Etant donnée une liste de nombres L, ordonnée ascendante, et 


un nombre N, la fonction PARTITION retourne un triplet 
Céléments-inférteurs-à-N &léments-égaux-à-N éléments-supérteurs-à-N) 


(DE PARTITION CN L) CCOND 
CCNULL L) CLIST O O O) 
((> CCAR L) N) LIST O © L)) 
CT CCGAMMA (CX Y Z) 
CIF C< CCAR L) N) CLIST CCONS CCAR L) X) Y Z) 
CLIST X CCONS CCAR L) Y) Z))) 
(SELF N CCDR L)))))) 


Voici l'implémentation du traitement des GAMMA-fonctions. Elle consiste à insérer 
dans APPLY avant la ligne | la clause 
stnst CA : Al) :: CC!Y ?-) GAMMA !X ?A2) alors 
app LIER; CA2 'APPLY3 Al : P) :: CIAL ?P); 
app PROGN 
Ainsi seul le premier élément de la liste A4 d'arguments évalués sera pris en 


compte. 
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L'implémentation de MULTIPLE consiste en 


1) la définition de la SUBR MULTIPLE 
2) la modification de EVLIS 


MULTIPLE pene 
i ("MULTIPLE : A4) :: !Al; derec 


L'indicateur MULTIPLE est placé en tête de la liste d'arguments évalués Ah. 


Cet indicateur sera détecté par EVLIS. 


EVLIS = | 
St Al :: ©) alors 
sinon (NIL : NIL) :: !A2; CA2 A2 : P) :: IP; 
tantque CAL Al : P) :: CCIAL !- ?-) ?P) fatre 
rec EVAL; 


St Al :: CMULTIPLE ?Al) alors 

sinon CAL : NIL) :: !Al 

fst 

P ii (C!- ?A2) !A3 ?P); Al :: !A3.CDR; 
jusqua Al :: C!-) fatre Al :: C!- ?A1) fjusq 
(A2 A2 : P) :: !P 


Al :: CAL); rec EVAL; 
st Al :: CMULTIPLE ?A1l) alors 


stnon (AI : NIL) :: !Al 

fst 

P :: C!A3 !A2 ?P); CAL : A2) :: C!A3.CDR !- ?AL) 
fst 
derec 


Ainsi, après chacun des deux appels récursifs de EVAL, si le résultat retourné 
est de type (MULTIPLE ?A1), EVLIS concatène la liste Al a la liste d'arguments 


évalués en construction. 
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La fonction MULTIPLE est trés utile pour la définition de fonctions 
de type STREAM (LANDIN 1966, STOY 1974, BURGE 1975a), dont l'application doit 


ramener deux resultats 
(MULTIPLE un-élément un-stream) 


Enfin, la généralisation évidente des GAMMA-expressions consisterait à 
considérer la liste d'arguments d'une fonction comme un filtre. 

La généralisation de MULTIPLE serait la possibilité systématique de ne sélec- 
tionner que certains des résultats ramenés par l'application des fonctions 
quotient et reste pour la fonction DIVIDE, adresse dans table et indication de 


débordement au prochain appel, dans une fonction de hash-code, etc. 
6.2.13.- LA FONCTION DE FILTRAGE 


La notation par filtrage qui nous a permis de décrire l'implémentation 
de VLISP est bien entendu implémentée dans toute sa généralité en VLISP sous 


la forme d'une fonction standard de type SUBR : 
CMATCH filtre argument) 


Les caractères préfixes (!), (?) et (,) indiquant le type des variables locales 


aux filtres sont implémentés par macro-génération (cf. §6.2.5.2). 


La fonction PAL teste si son argument est ou non un palindrome 


CDE PAL CL X) 
(MATCH 'C#ALT*® ©) 
C!-) 
(IX ?CL CPAL ,L)) !X)) 
L)) 


La fonction ISLAM teste si son argument est ou non une 


lambda-expression au sens du lambda-calcul 


CDE ISLAM CE X) | 
(MATCH 'C8ALT*® ICE (ATOM ,E) CNEQ ,E LAMBDA)) 
(ICE CISLAM ,E)) !CX CISLAM ,X))) 
(LAMBDA C!CX (ATOM ,X) CNEQ ,X LAMBDA))) 
ICE CISLAM ,E)))) 
ED) 
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La fonction ISREV teste si la liste Ll est image-miroir 


A tous les niveaux de la liste L2 


CISREV 'CCA B) C CC DE) FD) 'CCF CE DDD C CBA 22) >T 


CDE ISREV CL1 L2 X Y) 
CIF COR CATOM L1) CATOM L2)) CEQ LI L2) 
CAND (MATCH 'C?LI !X) L1) 
CMATCH 'C!CY CISREV ,X ,Y)) 
2(L2 CISREV ,L1 ,L2))) L2)))) 


6.3.- IMPLEMENTATIONS COMPAREES 


ant nu amas QUE mu eee ints ce ee QU A SS ee ee Se Ge ee ee ey ee sæ ee ety ee ee ee ten RS a a Cr 


Les deux versions occupent environ 5 K mots mémoire. Naturellement 


10/7) tire largement parti de sa capacité-mot de 36 bits et 


la version PDP 
de ses 16 registres généraux, contre 16 bits par mot et 4 registres généraux, 
3 registres de base et I registre pointeur de pile, pour le T1600. 

Sur PDP 10 un couple CAR-CDR est implémenté par deux demi-mots de 18 bits 


directement accessibles en lecture et écriture. 


La principale différence entre les deux versions est, en PDP 10 sous 
systeme DEC TOPS, la division du systéme en un segment partageable en zone 
haute (high segment) et un segment privé pour chaque utilisateur (low segment). 
Le segment partageable n'étant pas chargé dans sa zone privée, l'interpréte 
n'est pas modifiable par l'utilisateur comme c'est le cas sur T1600, qui 


~ 


autorise en VLISP l'accès en adresses absolues à l'interprète. 


(1) L'implémentation de VLISP PDP 10 a G46 réalisée par Jérôme CHATLLOUX 
(CHATLLOUX 1976: 9397795, 
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VLISP T1600 et VLISP PDP 10 ont en commun la rapidité de lancement 
des fonctions non-standard définies par lambda-expressions. Celles-ci sont 
toujours placées en-tête des P-listes de leurs atomes-noms : elles sont 
ainsi accessibles en deux indirections, et ne nécessitent pas une boucle 


de recherche dans la P-liste. 


Le lancement des fonctions standard est traité toutefois différemment 
sur les deux versions. Pour toute fonction standard f, la zone f.CODE 
contient en VLISP PDP 10 l'adresse de lancement, et deux champs supplémentaires 


f.REDEF et f.TYPE , qui indiquent 


pour f.REDEF : si la fonction standard a été redéfinie 
| ou non par l'utilisateur (cf. $6.2.1). 


Initialement 


f .REDEF NIL pour toutes les fonctions 


standard non redéfinies 


= T pour les atomes définis 


par l'utilisateur. 


pour f.TYPE : le nombre d'arguments et le type de la 
fonction standard SUBRO, SUBRI, SUBR?2, 
LSUBR, FSUBR. 


Grâce à ces indicateurs, le passage par EVLIS n'est pas effectué dans le 
cas de SUBRS à 0, I et 2 arguments, ce qui diminue le nombre de CONS 
nécessaires à la constitution de la liste des arguments évalués, et du 
même coup la fréquence des garbage-collections : les arguments évalués 


sont placés directement dans les registres de passage Al, A2, etc. 
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Nous illustrerons ce mécanisme en donnant l'implémentation de EVAL sur PDP 10. 


EVAL 


EVAL2 


tI 


St 
sinsi 


fst 


derece 


Al<HATOM alors AI.CVAL :: 


Al 


LA 
“we 
St 


stnst 


sinon 


fst 


AI 


tr {ALT (nombre ?-) (QUOTE !A1)) alors 
sinon (Al Al) :: 


C!A2 C!F 2A1)); 


F<HATOM alors 


St F.REDEF :: ©) alors 
stnst F.PLIST :: CEXPR !F ?-) alors 
(F : P) :: IP; rec EVLIS; CAL : P) :: ClAH TAL 2P); 
app APPLY 
sinst F.PLIST :: CFEXPR !F ?-) alors 
CF Al :: CIAL ?A4); app APPLY 
stnst F.PLIST :: CMACRO !F ?-) alors 
(F CA2 : NIL) 'EVAL : P) :: CIAL !A4 ?P); 
3 app APPLY 
fst 
St F.TYPE :: SUBR®? alors 
stnst F.TYPE :: SUBRI alors 
(Al F: P) :: CCIAL 2-) ?P); ree EVAL; P :: C!F ?P) 
stnst F.TYPE :: SUBR2 alors | 
(Al Al F : P) :: CCIAL ?-) ?P); ree EVAL; P :: CAD: 2P); 
Sv Al :: CMULTIPLE 'Al !A2) alors P :: CIF ?P) 
sinon CA2 Al : P) :: CC!- AL ?-) ?P); ree EVAL; 
CAL, SP: tt: CIA2 MAI IF ?P) 
Jer 
sinst F.TYPE :: LSUBR alors 
CE : P) ::!P; ree EVLIS; GAL : P) :: CIAL !F ?P); 
AY :: CIAL !A2 !A3 ?-) 
sinst F.TYPE :: FSUBR alors 
sinon (F F.CVAL) :: CIVARESC !F); app EVAL2 
fst 
app F.CODE 


F :: C{*ALT* LAMBDA GAMMA} ?-) alors 


tr C!F !A2 


LAL 


CF : P) :: IP; rec EVLIS; CAL : P) :: CIAL !AL ?P); 
app APPLY 

CF A2 Al : P) :: C!Al ?P); rec EVAL; CAI : P) 

app EVAL2 


2P); 
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6.3.2.- VARIABLES, FERMETURES ET ZONES DE CONTROLE EN VLISP, MACLISP, LISP 1.6 


m e y es yes es eu eye eg ee appr re er re eet tele eee eu ip pepe epee ep ee ee ee ee ee Gale HN eue a ee ee ee ee ee ee 


À (1) ne ir ag me 
Toutes ces versions ont en commun le principe des variables fluides 
l'avantage de ce schéma est de donner un environnement dans lequel 1'évaluation 


(2) 


d'un programme n'est pas figée par sa structure textuelle $ 


M, L et V considèrent toute variable comme a priori globale, et ont implémenté 
l'accès par C.valeur. I en revanche a adopté la division entre variables définies 
à la racine (toplevel) affectables par la fonction RPAQ, et variables définies 
dans la zone de contrôle, affectables par la fonction SETQ. Ainsi la zone de 
contrôle est,en I une version /[1néartsée d'une a-liste, gérée comme une pile. 
Cette décision diminue l'efficacité de l'accès aux variables mais facilite 


la compatibilité entre code compilé et code interprété. 


L et M peuvent traiter des funargs descendants, et non ascendants, par le 
mécanisme des pointeurs de contextes sur les valeurs préservées des variables 
en zone de contrôle. I et V peuvent traiter les deux types de funargs. Nous 

en avons examiné le mécanisme en V au §6.2.11. En Z c'est un tableau de couples 
variables-valeurs qui est inséré momentanément dans la zone de contrôle 

pendant l'évaluation du corps de la fermeture (cette insertion est coalesce 

par le mécanisme du SKIP-BLIP : TEITELMAN 1974 §12.11). L'inpléméntation de 

ces fermetures totales en V et J, ont pour les mêmes raisons l'inconvénient 


de ne pas permettre au corps de la fermeture de s'appeler récursivement. 


(1) Dans cette section, seront utilisées les abréviations V pour VLISP, M 
pour MACLISP, L pour LISP 1.6 et I pour INTERLISP. Toutes ces versions 
ont été implémentées sur ordinateur DEC PDP 10. 


(2) (STEELE 1976b) alias QUUX se fait l'avocat du principe opposé, de 
variables à portées définies lexicographiquement, essentiellement 
pour faciliter la tâche des compilateurs LISP. 
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De même, le nombre des zones de contrôle est très variable selon les versions. 
lb utilise deux piles : l'une pour la préservation des variables (spectal PDL), 
l'autre pour les adresses de retour et divers indicateurs (regular PDL). I 
utilise trois piles : une de variables-valeurs, une de contrôle, et une pile 
de traitement numérique. M dédouble cette dernière pour les valeurs inter- 


médiaires numériques entières (FXPDL) et flottantes (FLPDI). 


Nous avons pris en V la décision de ne mettre en jeu qu'une seule pile, pour 

ne pas multiplier les espaces mémoires distincts avec leurs limitations 
respectives, ce qui est critique pour l'implémentation de V sur mini~ordinateurs. 
Les pointeurs inter-piles des autres versions sont ici remplacés par des 
auto-pointeurs (cf. §6.1.4), la plupart deviennent toutefois inutiles et 


permettent d'économiser une place très précieuse. 


On constate selon les versions diverses limitations de fonctionnalité. L et 
yt? exigent la conformité du nombre d'arguments d'une fonction définie avec 
ceux présentés à l'appel. V et J laissent pleine liberté à ce sujet grâce au 
mécanisme décrit au §6.2.4. Cette décision présente l'avantage de permettre 
la définition très simple de variables de travail locales, sans faire usage 
de PROGS. 


Les divers types de fonctions ne sont pas applicables uniformément selon les 


versions. Ainsi I ne peut pas évaluer directement l'appel 
(Fer ses 22 
si f est une expression évaluable, mais exige un appel de type 


CAPPLY* fe, ... e ) 


n 


~~ 


L ne peut pas appliquer APPLY à des FSUBRS et FEXPRS, contrairement a V, M 
et I. L, Met I donnent accès à l'unique argument d'une LEXPR pour les 


fonctions CARG n) en lecture, et CSETARG n e) en écriture. Nous avons pris 


(1) De surcroît L n'utilise pas les PROGNS implicites pour les corps des 
lambda-expressions qui doivent être des expressions et non des suites 
l'évaluation séquentielle de suites d'expressions obligent en / à faire 
usage des PROGS. 
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en V la décision de ne pas suivre ce principe d'accés indexé, mais de donner 
accès par nom à l'argument d'une LEXPR, par souci d'uniformisation d'accés 
aux arguments, et pour faciliter la manipulation en bloc de la valeur de 
l'argument. 


Enfin V est seul à permettre l'application d'APPLY à une fonction de type 


MACRO. 


En ce qui concerne l'optimisation des appels récursifs, M interprète comme 
un branchement un appel post-récursif de lambda-expression à 0 arguments, 
ce qui y interdit la mise en place des constructions LESCAPE et SELF. 

V en revanche, met en jeu ces primitives, en interprétant itérativement les 
appels post-récursifs simples, mutuels et enveloppés, comme nous le verrons 


au chapitre 7. 


6.3.3. COMPARAISON DES CONSTRUCTIONS ESCAPE ET CATCH 


La construction ESCAPE de VLISP est plus puissante que la construction 
CATCH de MACLISP (MOON 1974, LAUBSCH 1976) à laquelle elle est apparentée. Sa 


forme de base est 
CCATCH x étiquette) 


qui évalue l'expression x et retourne sa valeur sauf si, au cours de l'évaluation 


de x, est évaluée l'expression 
CTHROW y La-même-étiquette) 


Dans ce cas y est évaluée et retournée immédiatement à l'appelant de CATCH. 
La faiblesse de la construction CATCH est, contrairement a ESCAPE, de ne pas 


avoir fonctionnalisé la notion d'étiquette. 
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Il est très aisé d'exprimer CATCH en VLISP en terme d'ESCAPE 


CDF CATCH CL) 
(APPLY "ESCAPE (LIST CCADR L) CCAR L)))) 


CDF THROW CL) 
CAPPLY CCADR L) CLIST CCAR L)))) 


En revanche il parait trés difficile, sinon impossible de définir ESCAPE 

en terme de CATCH sans modifier la structure de l'interprète. En effet, dans 
ESCAPE, en sortie de bloc par chute libre (évaluation de la fonction f d'échap- 
pement) ou en sortie normale, la liaison précédente de f considérée comme 


variable doit être restituée. 


Ainsi, pour exprimer : 


(ESCAPE f p «xe. G 


n 


avec l'un des &€ induisant l'évaluation de 
1 


CPs Saw dL) 


m 


CATCH devrait réaliser 


CLET CQ 'CLAMBDA V CTHROW a, PDD) 
(CATCH CPROGN e, ... e,) P) 

Ce qui, de surcroît supposerait que a, est connue à l'entrée du bloc-ESCAPE 
ce qui n'est évidemment pas le cas. 
ESCAPE ne peut pas être défini fonctionnellement une fois pour toutes en terme 
de CATCH comme nous l'avons fait dans le cas inverse : en effet, la fonction 
d'échappement f n'étant pas connue avant l'entrée dans le bloc-ESCAPE, le nom 
f n'est accessible que comme une valeur de variable. Or, dans tous les interprètes 
LISP, les modules de liaison et déliaison des variables n'opérent que sur des 
noms explicites, et ne peuvent pas lier et délier par acces indirect des noms 
qui sont des valeurs de variables. 

Donc la construction ESCAPE de VLISP ne peut pas être définie fonction- 


nellement en terme de CATCH sans modification de l'interpréte. 
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Une solution non-fonctionnelle consisterait en la macro~génération de 
chaque occurence de 
(ESCAPE fc, ... en) 
par 
(LET CCf 'CLAMBDA V (THROW CLAST V) f)))) 


(CATCH CPROGN e ... en) f)) 


Il est clair que cette solution est incompléte, car elle ne serait pas opérante 


dans le cas de 
(APPLY 'ESCAPE ?-) 
et dans 


CAPPLY 'f ?-) 
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CHAPITRE / 


INTERPRETATIONS ITERATIVES D'APPELS RECURSIFS 


7.1.- CONTINUATIONS ET ENVIRONNEMENTS : APPELS POST-RECURSIFS NORMAUX, MUTUELS ET 
ENVELOPPES 


Nous allons 4 présent montrer comment une particularité de la structure 
de l'interprète VLISP permet d'éliminer certaines formes très fréquentes de 
récursivité. 


Nous motiverons d'abord informellement notre démarche par quelques exemples. 


EXEMPLE | : POST~RECURSIVITES NORMALES 


La fonction LASTL livre, étant donné une liste L, le dernier sommet 
pendant gauche de L, représentée comme un arbre binaire, et explorée en 


ordre préfixe. 
CLASTL "CA CCB C) (D CEDDDD > E 


(DE LASTL CL) (COND 


EE serene ea CCCDR L) CLASTL CCDR L))) 
a CCATOM CCAR L)) CCAR L)) 
3 ----------------- (T CLASTL CCAR L))))) 


Les clauses 1 et 3 de LASTL comportent des appels récursifs. Si notre 
structure d'interpréte n'est pas appliquée, à chacun de ces appels seront 
préservés, dans la pile de récursion 

l'environnement : la valeur courante de l'argument L de LASTL 
. la continuation : en l'occurence une adresse de retour vers 


l'appelant de LASTL, ou vers LASTL elle-même. 
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Or nous savons (Mc CARTHY 1962d, PATERSON 1970, STRONG 1972) qu'il est 
inutile de préserver ici tant l'environnement que la continuation, le schema 


de LASTL permettant de le traduire en 


LASTL = st (CDR L) # NIL alors 
L + CCDR L); vers LASTL 

stnst (ATOM CCAR L)) alors 
résultat + CCAR L); stop 
sinon L + CCAR L); vers LASTL 


fst 


dont le schéma est itératif. 


Nous nommerons POST-RECURSIFS-NORMAUX (NPR), les appels de fonctions 


qui permettent une telle traduction. 


Nous voulons, sans avoir à effectuer cette transformation schématique, 


être en mesure d'interpréter itérativement les fonctions du type de LASTL. 


Nous entendons par interprétation itérative une situation telle que 
l'interprète reconnaisse dynamiquement le schéma de fonctions du type de 
LASTL, et prenne les mesures adéquates. 

Dans une interprétation itérative, ni l'environnement ,ni la continuation 


ne seront préservés inutilement. 


Naturellement, au premier appel de LASTL, tant l'environnement i.e. 
la valeur courante de l'argument L, que la continuation : l'appelant de 


LASTL, doivent être préservés, puis restitués en sortie du calcul. 


ans lk el ee ee Mer So CR, Saaana rine eR mr me a E A eo A os Pr nf S A TM LA A A Pk A EN POP a evans mand Stew» element 


A partir d'un appel de fonction LASTL, la figure suivante illustre la 
différence entre l'interprétation récursive et l'interprétation itérative 
ies appels successifs, en ce qui concerne l'utilisation de la pile de 


récursion. 


Soit l'appei de LASTL 


~ 


) avec Lot WAL. = 0 


NH 


(appelant CLASTL "CA (B)) 


re Ponte mess 


No 
INTERPRETATION RECURSIVE! 


ate re Pr apa EEE ne M d+ dr ae 


t 
peers renner erence tears -nya 


L 3 E 


ip 


i~petour-d-3s 


pkg A KES pst » CA (BD 

i bo É +. “y i ai -. = 

| He tour] ipetour-"d-] 
Act » a7 ast 5 Ue ir , a? 
ipetour-d-appe lant | re tour-d-appe lant | ne tour-ĝ-appe cant 
CLASTL. LECA (BDD) -—-s CLASTL L=CCB))) —> CASTE LADE se 
a [Lh Fd a > ASE 2 a? $ Q> 
A 
i petour-d-appe tant le tour-d-appe lant retour-d-appe lant 


INTERPRETATION ITERATIVE | 
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EXEMPLE 2 : POST-RECURSIVITES MUTUELLES 


La fonction PERMS doit, étant donné un entier positif n, imprimer la 
suite des permutations de l'intervalle [1,n] en ordre lexicographique. 


PERMS opére par backtracking. 


CPERMS 3) > (1 2 3) (1 3 2) C21 3) (2 3 1) (3 1 2) (3 2 1) 


(DE PERMS CN) CF 0 NIL)) 


CDE F CNIV E) 
CIF C< NIV N) CH C+ NIV 1) CCONS 1 E)) 
(PRINT CREVERSE E)) 
CG NIV CCAR E) (CDR E)))) 


CDE G CNIV X E) 
CIF C= X N) CIF E CG C- NIV 1) CCAR E) CCDR E)) 
'FINI) 
CH NIV CCONS (+ X 1) EDD 


CDE H CNIV E) 
CIF CMEMQ CCAR E) CCDR ED) CG NIV CCAR E) CCDR E)) 
CF NIV E))) 


PERMS fait appel aux fonctions auxiliaires de backtraking : 


F : fonction de génération et de descente 
G : fonction de correction si échec, et de remontée 


- H : fonction de vérification de la valeur générée par F. 


L'ensemble et le rôle des appels mutuels est résumé dans le diagramme 


4 he S à 
E) back track 


‘peri fier verifier nouvelle solution. eG 
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Nous avons ici affaire a trois fonctions mutuellement récursives, ou 
CO-PECUYSTVES. 


Dans le cas de la fonction G, l'appel 


CG C- NIV 1) CCAR E) CCDR E)) 


est clairement post-récursif normal. 
Tous les autres appels : G et H pour F, H pour G, F et G pour H sont les 
derniéres actions que G, H et F doivent accomplir et sont, par la transi- 


tivité de l'appel, co-postrécursifs. 


La traduction itérative de PERMS sera : 


PERGE Njye 03 E + NIL; 
i i st NIV < N alors NIV + NIV + l; 
E + (CONS 1 E); vers H 
sinon imprimer (REVERSE E) 
fst 
G = 
Ke (CCAR EDs E = (CCOR-E); 
St X = N. alors 
st E z NIL alors NIV + NIV - I 
vers G 
sinon stop 
fst 
sinon E + (CONS (X + 1) ED 
fst 
H = 


ST (CAR E) € CCDR E) alors vers G 
stnon vers F 


fst 


De méme que dans l'exemple 1, nous voulons que ces appels de G, F et 
H soient tnterprétés itérativement, sans transformations : seuls les premiers 
appels de F, G et H doivent préserver environnement et continuation. Tous 
les autres doivent être interprétés comme des branchements. 


Nous nommerons de tels appels CO-POSTRECURSIFS (CPR). 
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EXEMPLE 3.1 : POST-RECURSIVITES ENVELOPPEES 


La fonction LINEAR «aplanit» une liste L, i.e. livre la liste de tous 


ses atomes distincts de WIL rencontrés au cours d'un balayage préfixe. 


(LINEAR 'CA CCB C) (D CE))))) + (ABCD ED 


(DE LINEAR CL) CLIN L NIL)) 


CDE LIN CL R) CCOND 
CCNULL L) R) 
CCATOM L) CCONS L R)) 
Os pte NER CT CLIN CCAR L) CLIN CCDR L) R)DDD) 


On notera que la troisième clause de LIN est analogue à la troisième 
clause du programme récursif calculant la fonction d'Ackermann. 

Dans cette troisième clause, nous ne pouvons pas interpréter itérati- 
vement l'appel ap2 = CLIN CCDR L) R). En effet, cet appel est argument de 
l'appel imbriquant api = CLIN CCAR L) ... ). La continuation doit donc être 


préservée. Ici la continuation devra consister en la préservation de 


. LIN en attente, que nous nommerons fonctton enveloppe 


la valeur de CCAR L) déjà calculée. 


Cependant, l'appel ap2 = CLIN CCDR L) R) étant le dernter argument de l'appel 


apl, lui-même post-récursif, il serait inutile de préserver l'environnement. 


Nous nommerons un appel tel que ap2 POST-RECURSIF ENVELOPPE (EPR), et son 


interprétation : semt-ttérattve. 


Une traduction immédiate vient, éliminant de LINEAR les appels récursifs. 
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SENER BSN ES PENIG 


a j SL (ATOM L) alors 


St L 2 NIL alors R + (CONS L R) fst 


SL P z NIL alors 
L + CCAR P); P + CCDR P); 
vers LIN 
stnon résultat + R; stop 
fst 
sinon P + (CONS CCAR L) P); L + CCDR L); 
vers LIN 


fst 
La liste P joue ici le rôle d'une pile. 


Y seront préservées 


la valeur de CCAR L) déjà calculée, nécessaire à apl 
selon l'état vide ou non de la pile, l'indication d'arrêt du 


calcul, ou de sa reconduction par lancement de apl en attente. 


~ 


La structure de l'interprète VLISP permet à l'interprétation de LINEAR 


d'être équivalente en consommation de pile, à la traduction itérative vue 


plus haut. 
l. L'appel api sera interprété de façon strictement itérative. 
2. L'appel ap2 ne préservera pas inutilement l'environnement, 
seule la continuation sera préservée. 
EXEMPLE 3.2 


Dans de nombreux cas, nous aurons affaire à des fonctions comportant 


simultanément des appels de type NPR et de type EPR. 
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La fonction (DELETE X L) livrant de la liste L une copie d'où toutes 


les occurences de X ont été éliminées en est un cas. 


(DELETE 'A '(ABAACAAADA)) + (BCD) 


CDE DELETE CX L) CCOND 
CCNULL L) NIL) 
2 —------------ CCEQUAL X CCAR L)) CDELETE X (CDR L))) 
3 ------—----- (T (CONS CCAR L) (DELETE X CCDR LIDDY) 


Dans la clause 2, l'appel 
CDELETE X CCDR L)) 


étant NPR sera interprété strictement itérativement. 


Dans la clause 3, l'appel 
(DELETE X CCDR L)) 


étant EPR, avec CONS comme fonction enveloppe, l'environnement ne sera pas 
préservé, et l'appel sera interprété semi-itérativement. 

L'environnement, i.e. les valeurs précédentes de X et L, ne sera préservé 
qu'une seule fois : lors du premier appel. 

La profondeur de la pile nécessaire à la préservation des continuations sera 


linéairement proportionnelle au nombre d'éléments de L distincts de X. 


i denne sam- s: meee 
A TERRE 


EXEMPLE 4 


i étati i-itérati PR seront 
Les limites de l'interprétation semi itérative des appels E 


indiquées dans l'exemple suivant. 
La fonction COVL calcule la convolution des deux listes de nombres A 


et B. 


Si A = (a, a, ses a ) et bb, eee by 


n 
CCOVL A B) = } ab iy 


(DE COVL CA B) 
CIF CNULL A) 0 
D ees CCLAMBDA CX) (+ X ( CCAR A) CNEXTL B)))) 
CCOVL CCDR A) Bd) 


Dans la clause 2, l'appel EPR de COVL : 


CCOVL CCDR A) B) 


ne dott pas être interprété semi-itérativement par notre interpréte, la 


variable A étant 7tbre dans la fonction enveloppe : 
CLAMBDA CX) C+ X C* CCAR A) CNEXTL B)3)) 


Puisque CCAR A) fait référence à l'environnement ayant cours à l'appel de 
CCOVL CCDR A) B), cet environnement dott être restitué après cet appel. 
Il devra donc être préservé : l'interprétation doit être ici strictement 


récursive, tant la continuation que l'environnement doivent être préservés. 


Nous avons donné à VLISP une structure telle qu'un appel EPR d'une 
fonction f ne sera interprété semi-itérativement que si l'interprète est 


sûr que la fonction enveloppe de l'appel ne comporte pas d'occurences 


libres de f. 


7.2.- DEFINITION DES APPELS 


A présent, définissons plus précisément la classe des appels NPR, CPR 
et EPR. | 


7.2.1, 7 LA CLASSE _NPR 


7.2. 1.1.- Caractérisation statique 


Soit une définition de fonction 
CDE £ !- ?- elause-tf) 
dans laquelle 
clause-if ::= |(£ ?-) 


[CIF !- elause-tf ?-) 
ICIF !- !- ?- elause-tf) 
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L'alternant Cf ?-) de clause-1f est un appel post-récursif normal (NPR). 

Cette définition correspond à celle donnée dans (Mc CARTHY 1962d) des équations 
récursives sous forme itérative. 

VLISP interpréte itérativement de tels appels. 

Cette définition limite l'interprétation itérative aux fonctions nommées, 

notre structure d'interprète ne s'y limite pas et interprète également itérative- 


ment des fonctions anonymes, ou lambda~expressions. 


Soit la «boucle système supérieure» (cf. §6.2.]) suivante 


CCLAMBDA (ENTREE BOUCLE) 
(BOUCLE BOUCLE MESSAGE-INITIAL ENTREE)) 
CREAD) 
'CLAMBDA (BOUCLE SORTIE ENTREE) 
CIF CFIN-SESSION ENTREE) 'STOP 
(BOUCLE BOUCLE (PRINT CEVAL ENTREE)) CREAD))))) 


Elle peut s'exprimer avec la macro LET et la fonction SELF comme suit 
CLET CCSORTIE MESSAGE-INITIAL) CENTREE CREAD))) 
CIF CFIN-SESSION ENTREE) ‘STOP 
(SELF CPRINT CEVAL ENTREE) CREAD)))) 


L'appel NPR de BOUCLE (ou de SELF) est anonyme, et nous oblige 4 caractériser 
dynamiquement les appels NPR. 


7.2. 1.2.7 Caractérisation dynamique 


Soit SELF = (LAMBDA !- ?- clause-tf) 


Cette égalité est autorisée par le caractère de point fixe de SELF (cf. §6.2.10) 


dans laquelle 


clause-tf ::= |CSELF ?-) 
o- [CIF !- clause-if ?-) 
[CIF !- !- ?- elause-tf) 


L'alternant (SELF ?-) est un appel NPR. 
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On notera à propos de cette caractérisation que l'expression non-terminante 


bien connue 
CCLAMBDA CX) (X XD) 'CLAMBDA (X) (X X))) 
et ses variantes 


CLET CCX 'CLAMBDA ©) CSELF))) 
CX)) 


et 


(LET ©) CSELF)) : lambda-expression non-terminante sans 
arguments 


entrent dans la classe définie dynamiquement des NPR, et seront donc interprétées 


par VLISP itérativement. 


ee ee CUS QUE ee ee ee ee ee re 


Soit un ensemble de n définitions de fonctions 


CDE f. !~ ?- clause-tf) 


avec 
claner af TE CE, 2+) 
(CIF l=-clause-tf r=) 
[CIF !- !- ?- elause-tf) 
et t <j ,k Sn. 


L'alternant Cr ?-) de clause-tf est un appel co-postrécursif (CPR), et sera 
interprété itérativement si f, = f, (cas NPR) ou si la longueur de la chatne 


des appels successifs est 2n. 


EXEMPLE : soit les trois définitions 
(DE F CX) CG CP X22) 


CDE G CY) CH Q YDD) 
(DE H CZ) CF CR Z))) 
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L'appel initial CF A) provoque une évaluation interminable 


(FA) > GPA > CHCQ CP A))) > CF CR CO CP A9) 
l 2 3 


le troisième appel (F ?-) est CPR, sera interprété itérativement,de même que tous 


les appels qui lui succéderont. 


7.2. 3.- LA CLASSE EPR 


7.2. 3.1.- Caractérisation statique 


Soit une définition de fonction 
(DE £ !- ?- clause-env) 


dans laquelle 


elause~env ::= |C!fonetton-enveloppe ?- clause-tf) 


[CIF 1_ elause-env ?-) 
[CIF 1_ t_ 2. clause-env) 
et 
elause-tf Si oe) 
|CIF !- elause-tf ?-) 
\CIF !- !- ?- elause-tf) 


L'alternant (f ?-) de clause-if est un appel post-récursif enveloppé (EPR). 


VLISP interprète semi-itérativement de tels appels si la fonction enveloppe ne 


contient pas d'occurences libres des arguments de f. 
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De méme que pour la classe NPR, nous pouvons étendre cette définition aux appels 


EPR anonymes. 


7.2.3.2.- Caractérisation dynamique 


L'expression suivante livre une copie de L, si L n'est pas atomique. 


(LET CCX LD) 
CIF CATOM X) X 
CCONS CSELF CCAR X)) 
(SELF CCDR XDDD 


L'appel EPR CSELF CCDR X)) est anonyme, et nous améne 4 caractériser 


dynamiquement les appels EPR. 


Un appel (SELF ?-) est EPR si 
SELF = CLAMBDA !- ?- clause-env) 


avec clause-env définie comme en 7.2.3.1. 


et 
elause-tf ::= |CSELF ?-) 
[CIF !- elause-tf ?-) 
CIF t= [= ?- elause-tf) 
REMARQUES 


- |) Dans le cas des appels NPR et EPR, l'interprète VLISP 
est tout à fait insensible aux noms de fonctions et la possibilité 
d'interpréter itérativement des fonctions anonymes s'étend naturel- 
lement aux cas de fonctions à types circulaires (LEDGARD 1972, 


ROBINET 1977). 
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EXEMP LE 


Voici une fonction de calcul de factorielle a type circulaire 


CSETQ G 'CCLAMBDA CL X) 
CIF Œ X 0) 1 
C! X CCCAR LD L C- XDDD 


Le type de la fonction est 


(a x N> N x NON 
avec 


a=axNoNn 


Pour obtenir factorielle n, il nous suffira d'appeler 
-CCCAR G) G N) 


Il paraît très difficile de faire reconnaître à un compilateur 
la récursivité d'un tel programme, essentiellement détectable 
à l'exécution et de lui faire appliquer des transformations 
telles que celles décrites dans (RISCH 1973, BURSTALL 1975). 
L'interpréte VLISP reconnaîtra cependant aisément l'appel de 
CCCAR L) L C- X 1)) comme étant EPR et l'interprétera semi- 


itérativement. 


- 2) Notre caractérisation interprétative des appels EPR est 
tout à fait distincte de celles données dans (PATERSON 1970, STRONG 


1972) qui distinguent les schémas linéaires et non linéaires. 


En effet les schémas 


. de la fonction d'Ackermann 


(DE A CX Y) 
CIF (C= X 0) (+ Y 1) 
(A C- X 1) 


CIF C= Y 0) 1 
(AX CG Y 1)))))) 
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. de La fonction 91 de Mc CARTHY (MANNA 1968) 


(DE F91 CX) 
CIF  X 100) C- X 10) 
CF91 CF91 C+ X 11))))) 


sont non-linéaires. 


Néanmoins VLISP interprétera semi-itérativement les appels enveloppés 


CA X C- Y 1)) 


et 


CF91 C+ X 11)) 


En revanche, bien que le schéma suivant (PATERSON 1970) 


(DE F CX) 
CIF CP X) CR X) 
CS CF CQ X)) X))) 


soit linéaire, VLISP n'interprétera pas semi-itérativement l'appel 


CF CQ X)) qui n'est pas EPR. 


- 3) Les caractérisations NPR, CPR et EPR ont été données en terme 
de la fonction de contréle IF. Les interprétations correspondantes sont 
étendues naturellement aux fonctions de contrôle COND, AND, OR et SELECTQ, 
qui bien que primitives en VLISP peuvent étre définies formellement en 


terme de IF. 
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7.3.7 DESCRIPTION DE L' IMPLEMENTATION 


Examinons à présent quelle est la structure de VLISP qui va permettre 
l'interprétation itérative des appels NPR et CPR, et l'interprétation semi- 
itérative des appels EPR dans les cas sürs. 

Nous donnerons tout d'abord les algorithmes, puis nous les justifierons 
en construisant un interprète abstrait de VLISP sous forme de «règles de 
vérification» décrivant les états de la pile de récursion, à l'entrée et à 
la sortie de chacun des modules de l'interprète. 

Nous donnerons successivement les caractéristiques de VLISP qui 


permettent d'abandonner de façon sûre 


1) la continuation 


2) l'environnement 


7.3. 1.- ABANDON DES CONTINUATIONS 


Dans la caractérisation que nous avons donnée des 
appels NPR et CPR, nous notons une propriété commune : l'appel post- 


récursif (PR): Cf ?-) Cf ?~) ou (SELF ?-) est traité 


1) ou bien par un appel direct à EVAL dans le cas de 
CIF !- appel-PR ?-) 


2) ou bien en étant le dernier élément à évaluer d'un 


PROGN implicite 
CLAMBDA !- ?- appel-PR) 
ou 


CIF !- !- ?- appel-PR) 
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Le premier cas, appel direct à EVAL est un branchement avec un passage de 


message : les arguments évalués de l'appel-PR. 


Le cas du PROGN va nous retenir un moment. 


Si le PROGN était défini comme suit en FILTRE 


PROGN = 
Al :: !A2; 
tantque (A2 A2 : P) :: CC!IALl ?-) ?P) fatre 
ree EVAL; P iz: CC!- ?A2) ?P) 
ftan 
derece 


ce qui, en VLISP s'exprimerait 


(DE PROGN CL) 
CLET CCL L) CVAL L)) 
CIF CNULL L) VAL 
(SELF CCDR L) CEVAL CCAR L)))))) 


le dernier élément d'un PROGN, même à être un appel NPR ou CPR serait évalué 
récursivement : une continuation dans la boucle tantque aurait été préservée. 
Pour éviter cette difficulté, nous sommes amenés à dédoubler l'appel de EVAL 
en un appel récursif pour tous les éléments sauf le dernier, et en un bran- 


chement direct avec message dans le cas du dernier élément. 


Nous aurons alors en FILTRE 


PROGN = 
tantque (Al Al : P) :: CC!IAL !- ?-) ?P) fatre 
rec EVAL; P :: CC!- ?2A1) ?P) 
ftan 
Al :: C'AL); app EVAL 


en observant au passage que ce dédoublement nous permet de faire l'économie 


du second registre A2. 
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Cette modification correspondra en VLISP a 


(DE PROGN CL) 
CIF (NULL CCDR L)) 
RES CEVAL CCAR LD) 
CEVAL CNEXTL L)) 
CPROGN L))) 


EVAL prendra alors, à son appel final, le contrôle de la continuation (clause 
Celle-ci sera alors préservée s'il s'avére que l'appel n'est pas CPR ou 


NPR. 


A présent, reste à traiter le problème de la gestion des environnements. 


REMARQUE 
On observera en passant que si le langage LISP n'avait 
autorisé que les fonctions à 0 arguments, l'algorithme 
précédent à lui seul nous aurait garanti l'interpréta- 


tion itérative de fonctions telles que 


f = (LAMBDA O CIF ce e ...e | Ct) 


qui auraient donné à leur appel un calcul dynamiquement 
équivalent à la traduction 


tantque non c fatre eval(e ); ... ; eval(e |) ftan 
eval(e ) 


Ainsi, un programmeur, assez occupé à construire ses procédures sous leur 
forme la plus naturelle ne serait pas voué à décider si les formes récursives 
ainsi mises en jeu sont ou non nécessaires, comme le recommande N. WIRTH 


(1976 p. 127 §3.2 «When not to use recursiom ). 
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7.3.2.- ABANDON DES ENVIRONNENENTS 


Dans les implémentations traditionnelles de LISP, c'est le module APPLY qui 

a charge de préserver, puis de restituer les environnements. 

Rappelons que dans le cas de VLISP, un environnement est l'ensemble des valeurs 
des arguments d'une fonction précédant son appel. 

Nous appelerons environnement redondant un environnement préservé par un appel 
de fonction NPR, CPR ou EPR, dans le cas où cet environnement ne sera jamais 
plus utilisé. 

C'est en particulier le cas dans les appels de type EPR, ces appels étant 
précisèment le dernier argument à évaluer d'une liste d'arguments. 

C'est la fonction EVLIS qui, se chargeant d'évaluer une liste d'arguments, 
devra fournir l'indication que l'appel EPR est bien le dernier à devoir être 


évalué. 


7.3.2.1.- Structure d'EVLIS 
Si EVLIS était ainsi définie en FILTRE 


EVLIS = 


() :: !A2; 
jusqua Al :: ©) fatre 
(A1 A2 Al : P) :: CC!'AI ?-) ?P); 
ree EVAL; 
P :: C!A2 ?P); 
(CAL : A2) : P) :: C!A2 C!- ?A1) ?P) 
fous 
A2 :: !Al; app REVERSE 


ce qui en VLISP s'exprimerait 


(DE EVLIS CL) 
CIF CNULL L) NIL 
(CONS CEVAL CCAR L)) 
CEVLIS (CDR L))))) 


nous n'aurions aucun moyen de distinguer si EVLIS passe ou non a EVAL le dernter 
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élément de sa liste. 

De même que dans le cas de PROGN (cf. §7.3.1), nous devons effectuer une 
duplretfon de l'appel de EVAL : un premier appel récursif pour tous les 
éléments sauf le dernier, enfin un second appel récursif pour le dernier. 
La continuation de retour empilée alors par ce dernier appel donnera à 


l'interprète VLISP l'indication lui permettant de détecter un appel EPR. 


(1) 


Nous aurons alors en FILTRE 


EVLIS = 
C) :: !A2; 
jusqua Al :: C!A1) faire 
(Al A2 Al : P) :: CC!AL ?-) ?P); 
ni ler appel -----—- reco EVAL; 
EVLIS2 = 
P :: C!A2 ?P); 
CCAl : A2) : P) :: CIA2 C!- ?A1) ?P) 
fiusqa 
EVLIS3 = 
CA2 : P) :: IP; 
ree EVAL; 0:22). 00 QéEME appel —------- 
EVLIS4 = 


P iz CAD ?P); CAL : A2) :: !Al; 
app REVERSE 


Ce qui en VLISP donnera 


(DE EVLIS CL) 
CIF CCDR L) CCONS CEVAL CCAR L)) 
CEVLIS CCDR L))) 
(LIST CEVAL CCAR L))))) 


(1) C'est par souci d'alléger l'exposé que nous donnons cette version d'EVLIS, 
construisant dans A? une liste d'arguments évalués en ordre inverse de 
leur présentation, ce qui explique le dernier appel non récursif 4 REVERSE. 
Bien entendu, l'interprète VLISP tel qu'il est implémenté sur T1600 et 
PDP 10 met en jen la méthode équivalente, mais plus efficace, d'accrochage 
de bords (cf. $6.2.1) qui évite d'avoir à dé-inverser la liste des 
arguments Gvalués. 
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7.3.2.2- Structure d'APPLY 


Nous disposons à présent de toutes les informations nécessaires pour 
indiquer comment APPLY se chargera de détecter les environnements potentiel- 


lement redondants, et de ne pas les préserver. 


Lorsque APPLY doit traiter une lambda-expression exp et une liste 
d'arguments argliste, il examine si l'état de la pile indique que cette 
lambda-expression a été ou non appelée précedemment. Si cet état indique 
que l'appel de exp est CPR ou NPR, il ne sauvera pas l'environnement de 


exp sur la pile, se contentant 


1) de lier les paramètres formels de exp à ses paramètres 


actuels évalués, éléments de argliste 


2) de passer directement le corps de exp à PROGN, qui prend 


totalement le contrôle. 


Si, en revanche, cet état indique que l'appel de exp est EPR, APPLY effec- 


tuera 


1) comme precedemment 
1.1) préservera la continuation sur la pile 


2) comme précedemment 


Si, enfin, cet état indique que l'appel de exp n'est pas post-récursif, 


APPLY 
1.1) sauvera l'environnement sur la pile 
1.2) effectuera les liaisons comme dans les cas précédents 


1.3) sauvera sur la pile 
1.3.1) la lambda-expression exp elle-même 
1.3.2) une continuation vers un module de 
restitution des arguments 


2) comme dans les cas précédents. 
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Nous obtenons alors la structure suivante pour APPLY, dans les cas qui nous 


intéressent : 


APPLY 


st ÇA : Al) :: C!Y LAMBDA !X ?-) alors 
St P iz CEVLIS4 !- {ALTS ,AI Cmarq ?-)} !- ,Al ?-) 
alors app SIMPLE-LIER; 
CAL Al : P) :: CCLAMBDA !- ?A1) ?P); 


rec PROGN; 
APPLY4 = 
P :: C!- ?P); derec 
stnst P :: CAPPLY4 ,Al ?-) alors 
app SIMPLE-LIER; 
Al :: CLAMBDA !- ?A1); app PROGN 
sinon P :: ! TEMP; 
tantque TEMP :: CAPPLY3 !Z !- ?TEMP) fatre 
st Z :: ,Al alors 
app SIMPLE-LIER 
Al :: CLAMBDA !- ?A1) 
app PROGN 
fst 
ftan 
app LIER; 
CAI Al : P) :: CCLAMBDA !- ?A1) ?P); 
rec PROGN; 
APPLY3 = 


PCs 9P) > app DÉLIER 
derec 
fst 
fst 


Dans cette version, LIER et DELIER sont définis comme au $6.2.3 , avec, 

pour ne pas rendre l'exposé trop lourd, la présupposition que n'est 

placé sur la pile qu'un potnteur (ne comptant alors que pour un élément) 

vers une zone de sauvetage des arguments. 

SIMPLE-LIER, qui, sans préserver l'environnement, ne fait que lier les 
arguments (dont la liste est dans X) 4 leurs nouvelles valeurs (dont la liste 


est dans Y) aura la structure 


SIMPLE-LIER = 
jusqua X<HATOM fatre 
CON) Bo COIR SKI CTT 


Yl :: !X1.CVAL 
fjusq 
St X :: ©) alors 
sinon Y i: !IX.CVAL 
fst 


ret 
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7.4.- JUSTIFICATION DE L' IMPLEMENTATION 


Si le comportement des programmes interprétés itérativement est tout 
a fait clair, l'implémentation réalisant ces comportements n'est pas parti- 
culièrement intuitive. Il est alors utile de préciser l'organisation de la 
pile de récursion et la nature des éléments qui y figurent, au fur et 4a 
mesure que les calculs se déroulent. 
Ce sont précisèment les propriétés de cette organisation qui peuvent nous 
assurer que les comportements souhaités sont effectivement réalisés. La 
tentative de preuve, qui suit, de ces propriétés n'est pas totalement a 
posteriori : dans le cas de l'interprétation des appels EPR, elle a précédé 
et guidé l'implémentation. Le va et vient plus haut décrit, en programmation 
entre raisonnement a priori et intuition empirique s'est ici réalisé de 


gauche à droite. 


UN INTERPRETE VLISP ABSTRAIT 


Pour justifier les interprétations itératives et semi-itératives des 


appels NPR, CPR et EPR, nous allons procéder comme suit 
1) donner en VLISP le noyau de l'interprète VLISP 


2) extraire de cet interprète un ensemble de «règles de 
vérification» qui, pour chacun de ses modules décrira 
les états de la pile de récursion à son entrée et a sa 
sortie. 

L'ensemble de ces règles, comparables à une «history» 


(CLINT 1973) constituera un interprète VLISP abstrait. 


L'examen de ces règles nous permettra d'expliquer et de justifier nos algo- 


rithmes d'élimination de récursivités. 
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Rédigé dans le «style langage-machine» de (SUSSMAN 1975), nous considé- 
rerons que toutes les variables mises en jeu sont globales. L'appel (save x) 
empile x sur la pile stack, l'appel (restore) livre l'élément en sommet de pile 
dépilé. La pile stack sera gérée comme une liste. La fonction cval livre la 
C.valeur de la variable qui est la valeur de son argument. 


On observera que cet interprète ne comporte pas d'appels récursifs. 


MODULES SYSTEME 


(de run () (setq pe 'toplevel) (Loop)? 


(de loop () (while t (pe))) 


Le module run sert a lancer l'interpréte. Le module loop est une boucle de 
contrôle non-terminante qui lance le «prochain» module. L'« adresse» de ce 
module est la valeur de la variable pe qui joue le rôle d'un compteur 
ordinal. 

La boucle-supérieure-systéme toplevel est le premier module lancé par loop 
elle effectue quelques initialisations, assure la lecture d'une expression a 
évaluer dans le registre exp, et passe le contrôle à eval en empilant une 
continuation de retour vers le module top qui se chargera d'imprimer l'expres 


sion évaluée, et de relancer le module toplevel a nouveau. 


(de toplevel () 
(setq link ntl stack nil exp (read) pe ‘eval) 
(save 'top)) 
(de top () (print exp) (setq pe 'toplevet)) 
La fonction unrec réalise le retour récursif, en plaçant dans pe la continua- 


tion de retour extraite du sommet de pile. 


(de unree () (setq pe (restore))) 
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MODULES EVALUATEURS 


Voici a présent les modules eval, evlis et apply, enchainés en pipe- 


line. 


(de eval () (cond 
((numbp exp) (unrec)) 
((atom exp) (setq exp (eval exp)) (unrec)) 
(t (setq hdexp (ear exp) 
tlexp (edr exp) pe ‘evall)))) 


(de evall () (cond | 
((listp hdexp) (save hdexp) (setq pe 'evits exp tlexp)) 
((or (get hdexp 'expr) (get hdexp 'subr) ) 
(save hdexp) (setq pe 'evlis exp tlexp)) 
((setq temp (get hdexp 'fexpr)) 
(seta arglist (list tlexp) exp temp pe ‘app Ly) ) 
((get hdexp 'fsubr) (setq pe hdexp exp tlexp)) 
((setq temp (get hdexp 'macro)) 
(setq arglist (list exp) exp temp pe 'apply) (save ‘'eval)) 
(t (setq hdexp (cval hdexp))))) 


Le module eval régle le cas des nombres et des variables, et sinon passe a 
evall l'expression dans exp décomposée, qui réglera le cas des divers types 


possibles de fonctions : expr, fexpr, subr, fsubr, macro. 


Le module evlis reçoit dans exp une liste d'arguments a évaluer. 


(de evits () 
(tf (null exp) 
(setq exp (restore) arglist nil pe apply) 
(setq built nil pe ‘evitsi))) 


(de evlisl () 
(if (null (edr exp)) (setq pe 'evits3) 
(save exp) (save built) (save 'evlisz) 
(setq exp (car exp) pe ‘eval))) 
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Dans le registre built est construite la liste des arguments évalués. 


(de evlis2 () 
(setq butlt (ncone (restore) 
(tf (eq (car exp) 'multtple) 
(edr exp) (list exp))) 
exp (edr (restore)) 
pe ‘evlts1)) 


(de evlts3 () 
(save built) (save 'evits4) (setq exp (car exp) pe 'eval)) 


(de evlis4 () 
(setq argltst (neone (restore) 
(tf (eq (car exp) 'multtple) 
(edr exp) (ltst exp))) 
exp (restore) 
pe 'apply)) 


Le module apply regoit une supposée fonction dans exp et une liste d'arguments 


supposés évalués dans arglist. 


(de apply () (cond 
((atom exp) (cond 
| ( (setq temp (or (get exp 'expr) (get exp 'fexpr))) 
(setq exp temp)) 
(for (get exp 'subr) (get exp 'fsubr)) 
(setq pe exp)) 
(t (setq exp (cval exp))))) 
((neq (car exp) 'lambda) (save arglist) (save 'apply2) 
(setq pe 'eval)) 
(t (setq À-exp exp) 
(cond 
((and (eq (ear stack) 'evlis4) 
(eq (caddddr stack) r-exp) 
(or (eq (caddr stack) d-exp) 
(get (caddr stack) 'subr))) 
(save \-exp) (save 'apply4) 
(simple-bind (cadr r-exp) arglist) 
(setq exp (eddr \-exp) pe 'progn)) 
((eq (cadr stack) i-exp) 
(simple-bind (cadr d-exp) arglist) 
(setq exp (cddr -exp) pe 'progn)) 
(t (setq temp stack pe 'applyi)))))) 
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(de apply1 () (if (eq (car temp) 'applyé) 

(tf (neq (cadr temp) d-exp) 
(setq temp (edddr temp)) . 
(stmple-bind (cadr À-exp) arglist) 
(setq exp (cddr d-exp) pe 'progn)) 

(bind (cadr -exp) argltst) 

(save \-exp) (save ‘apply3) 

(setq exp (eddr d-exp) pe 'progn))) 


(de apply2 () (setq arglist (restore) pe ‘apply)) 
(de apply3 () (restore) (unbind) (unrec)) 


(de apply4 () (restore) (unrec)) 


MODULES DE LIAISON D'ENVIRONNEMENTS 


Voici à présent les modules de liaison et déliaison des arguments des 
fonctions interprétées : le module bind sauve le pointeur de liaison Link 
et l'environnement sur la pile et affecte les arguments (dans la liste x) 


avec les nouvelles valeurs (dans la liste y). 


(de bind (x y) | 
(setq temp (list link)? 
(while (listp x) 
| (setq temp (cons (cons (car x) (eval (car x))) temp)) 
(set (nextl x) (nextl y))) 


(and x (setq temp (cons (cons x (eval x)) temp)) 
(set x y)) 


(save temp) (setq link stack)) 


i 203 . 
en 


Le module unbind restaure l'environnement précédent et remet å jour le 


pointeur de liaison tink. 


(de unbind () 


(setq temp (restore)) 
(whtle (edr temp) 


(set (caar temp) (edar temp)) 
(setq temp (edr temp))) 
(setq Link (car temp))) 


Le module stmple-bind ne préserve pas l'environnement et ne fait 


qu'affecter les arguments à leurs nouvelles valeurs. 


(de stmple-bind (x y) 
(while (listp x) 


(set (nextl x) (nextl y))) 
(and «(set x-y?) 


MODULES DE CONTROLE 


Voici a présent le module de séquencement progn. 


(de progn () 


(tf (null (edr exp)) nil (save exp) (save 'progn1)) 
(setq exp (car exp) pe ‘eval)) 


(de progni () 
(setq exp (edr (restore)) pe 'progn)) 
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Enfin, en nous limitant au type primitif de module de contrôle, voici 


le module if de type FSUBR. 


(AF TI 49 
(save exp) (save 'tf1) 
(setq exp (car exp) pe 'eval)) 


(de. 24 (0 
(if exp (setq exp (cadr (restore)) pe ‘eval) 
(setq exp (cddr (restore)) pe 'progn))) 


-m x eu cee pet ee ee dala ee ce ee ee ee ee ee ee dé 


Pour justifier la validité de nos interprétations itératives et semi- 
itératives, nous allons extraire de l'interprète précédent des règles de 


vérification, de la forme 


otat-d'entree-S1 {P1} module-sutvant-P2 etat-de-sortie-S2 


dans lesquelles SI sera l'état de la pile a l'entrée du module Pl, S2 est 
l'état de la pile en le quittant, P2 sera le nom du prochain module à être 
lance. 
Lorsque PI se termine par le retour récursif (unrec), l'identificateur 
reteont («return continuation») sera substitué à P2 : signifiant ainsi un 
retour récursif à l'adresse placée en tête de la pile. 

Les états de pile seront codés par des mots sur un alphabet de noms 


de modules et d'expressions, reconnaissables par filtrage. 


EXEMPLE 


hae’ 


Si, à l'entrée de eval nous avons l'état de pile 


(?a) 
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l'examen du module indique que nous aurons en sortie l'état de 


pile 
{XALT* Clreteont ?a) Cevall ?a)} 
la régle de vérification aura ee la forme 
C?a) {EVAL} [ALT C!retcont ?a) Cevall ?a)} 


Dans ce qui suit, nous simplifierons les écritures de telles 


règles par 
a {EVAL} reteont:a v evatlia 


Le signe «y» séparera les différents états de sortie possibles, 


le signe «:» sera comme auparavant l'abréviation de CONS. 
Les régles auront alors la forme générale 
SLAP) 22:82 V 4,4. V Pn:9n 


Nous donnerons, extraites de chaque module, l'ensemble des règles de vérifi- 


cation définissant l'interprète VLISP abstrait. 


MODULES EVALUATEURS 


o {EVAL} retcont:a v evall:a 


a {EVALI} apply:a v evlis:hdexp:a 
v fsubr':o 
v evallia 


V apply:eval:a 
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hdexp:a {EVLIS }evlisl:hdexp:a v apply:a 

hdexp:a {EVLISI} evlis3:hdexp:a V eval:evlis2:built:exp:hdexp:a 
built:exp:hdexp:a {EVLIS2} evlis1:hdexp:a 

hdexp:a {EVLIS3} eval:evlis4:built:hdexp:a 


built:hdexp:a {EVLIS4} apply:a 


a{APPLY}appiy:a v subr:a 
v fsubria 
v eval:apply2:arglist:o 
v progn':apply4:1-exp:o 
v progn:a 
v applyl:a 
a{APPLYI}applyl:a v progn:a 


v progn:apply3:A-exp:env:a 


REMARQUE : env désigne ici l'environnement de la \-expression précédant 


son appel. 


arglist:a{APPLY2}apply:a 
A-exp:env:a{APPLY3}retcont:a 


A-exp:a{APPLY4}retcont:a 
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MODULES DE CONTROLE 


P {PROGN}eval:B y eval:prognl:exp:8 


exp: {PROGN] }progn:8 


B {IF }eval:ifl:exp:ß 


exp:ß {IF] }eval:B y progn:ß 


7.4.3.- JUSTIFICATION_DES_INTERPRETATIONS_ITERATIVES 


Ces règles vont nous permettre de justifier les algorithmes 


d'implémentation. 


7.4.3.1,- Appels NPR 


H 


soit foo (À (xl ... xn) el ... em) 


avec em = (foo al ... an) 


PROPOSITION ] 


Soit a l'état de la pile lorsque le module PROGN est lancé 
avec exp = (el ... em), 

soit a’ l'état de la pile lorsque le module EVAL est lancé 
avec exp = em, 


ii 


alors a =a’. 


208 


PREUVE 


Soit exp = (el ... em) 
avec a{PROGN} 
1) Si m = | nous aurons 
af PROGN}eval:a 
et par conséquent 
a{ EVAL} 
2) Si m > I nous aurons 
a{PROGN}eval:prognl:exp:o 
et, si l'évaluation de el ne diverge pas, nous obtiendrons 
exp :a{PROGNI }progn:a 
suivie de 
a{PROGN} 


la longueur de exp étant à présent m ~ | 


PROPOSITION 2 


Ce n'est qu'à l'évaluation de em que nous pouvons trouver 


foo en sous-sommet de pile, 


l.e. 
apply3:foo:env. :a{EVAL} 
ou 
apply4:foo: a{EVAL } 
PREUVE 


Supposons que exp = ek avec k # m 
L'état de la pile à l'entrée de EVAL sera 
progni:(ek ... em) :B{EVAL } 
et, puisque (ek ... em) est un CDR de foo, il ne peut pas 


être physiquement égal a foo. 
C] 
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PROPOSITION 3 : 


Enfin nous devons montrer que si aucun des ei, 1 <i<m 
ne diverge å son évaluation, l'environnement de foo précédant 


son premier appel sera restitué. 


PREUVE : 


Si exp = em, trois cas d'états de pile sont à considérer 
1) apply3:foo:env, :a{APPLY} 
Au retour d'APPLY nous aurons l'état de pile 
foo:env, :a{APPLY3}retcont:o 
et APPLY3 restituera par UNBIND l'env,, précédant le 
premier appel de foo. 
2) Si exp = em avec 
apply4: foo:evlis4:built:hdexp:apply4:foo:B{APPLY} 
alors APPLY4 restituera l'état de pile 
built:hdexp:apply4:foo:B{EVLIS4} 
et EVLIS4 donnera 
apply4:foo:B{ APPLY} 
3) Si exp = em avec 
apply4:foo:evlis4:built:hdexp:apply3:foo:@{ APPLY} 
alors APPLY4 donnera 
built:hdexp:apply3:foo:@{ EVLIS4} 
et EVLIS4 laissera sur la pile 
apply3:foo:@{ APPLY} 
Ainsi le second et le troisième cas se ramènent au premier, 


et APPLY3 restituera l'env,.: 
O 


Nous pouvons être sûrs qu'un appel de lambda-expression traité par APPLY, et tel 
que la même lambda-expression est l'élément de sous-sommet de pile, cet appel 1a 


est NPR, et peut être traité comme un branchement. 
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7.4.3.2.- Appels CPR 


Soit F un ensemble de n fonctions mutuellement post-récursives. 
Nous devons montrer qu'à partir de n appels mutuels au plus de 


ces fonctions, nous nous retrouvons dans le cas NPR. 


PROPOSITION | 


Soit A l'ensemble des m appels déjà lancés. 


Si m > n alors A comprend plus d'un appel à une même fonction. 


PREUVE : 


Par le principe des tiroirs, en comptant l'appel initial d'une 
des n fonctions, 
[Al = m+l ; IF| =n 
et l'application A + F ne peut pas être injective. 
g 


PROPOSITION 2 : 


Soit stack la pile, foo la fonction appelée, top l'adresse du 
sommet de pile, alors, à l'entrée dans APPLY au m-iéme appel 
Ji € [0 , n-i] tel que 
1) vj € [O , i] 
stack(top ~ 3j) = APPLY3 
2) stack(top - 3i - 1) = foo 


211 


PREUVE : 


1) si 1=0 nous sommes ramenés au cas NPR 
2) si 120, nous utiliserons l'exemple des trois fonctions 


mutuellement post-récursives 
(de f£ (x) (g b)) 
(de g (y) (h c)) 
(de h (z) (£ d)) 


Soit l'appel initial (f a) , lançant un calcul non- 
terminant. 
Par construction, avant l'évaluation de (g b) , nous 
aurons l'état de pile 

apply3:f:envç :a{APPLY} 
puisque l'appel (g b) est post-récursif. 
Avant l'évaluation de (h c) , nous aurons 

apply3:g:env, :apply3:f:envç :a{APPLY} 
et de même, avant l'évaluation du troisième appel mutuel, 
(f d) celui-ci CPR 

apply3:h:env, :apply3:g:env, :apply3:f:env, :a{APPLY} 
et, avec 1=2, à l'appel de (fd) nous trouvons 
stack(top) = stack(top - 3) = stack(top - 6) = apply3 
et stack(top - 7) =f 
O 


On en déduit l'algorithme de détection dans APPLY d'appels CPR 


P iz ITEMP; 

tantque TEMP :: CAPPLY3 !Z !- ?TEMP) fatre 
st Z :: ,Al alors <trouvé> fst 

ftan 


<cas non-CPR> 
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Le délai associé à cette structure d'interprète est 


1) pour tous les appels : un test vérifiant si l'élément en 


sommet de pile est égal à l'adresse 


APPLY3 ou APPLY4 


2) pour les appels CPR : le nombre de tests est au plus propor- 


tionnel au nombre d'appels NPR précédents 


de fonctions distinctes. 


Ce délai est compensé 


1) par une économie de temps : les environnements non préservés 
ne seront pas visités et marqués par le garbage- 
collector. De plus, au retour, ces environnements ne 


seront pas passés au module de restitution 


2) par une économie d'espace pile utilisé. 
L'espace utilisé effectivement dans le cas CPR est propor- 
tionnel au tronçon initial de fonctions toutes distinctes 
s'appelant successivement de façon non récursive : tous les 
appels succédant aux n- | premiers appels au plus, seront 
gratuits en occupation de pile. | 
Le gain est total pour tous les appels récursifs. Ce gain 
peut être infini dans le cas de fonctions non-terminantes 


telles que les boucles~systéme. 
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7.4.3.3.- Appels EPR 


Soit f une fonction comportant un appel EPR 
(g al a2 ... an) 
g étant la fonction-enveloppe, avec 


an = (f ?-) 


PROPOSITION 1 


L'appel EPR (f ?-) pourra être interprété semi-itérativement 
par non-préservation de l'environnement, si g est 
1) une fonction standard 


2) ou bien f = g 


PREUVE 


L'interprétation est sûre si g ne comporte pas d'occurences 
libres d'arguments de f. 

C'est le cas par définition pour les fonctions standard 

qui ne comportent pas de variables : ni libres, ni liées. 


Si f = g toutes les occurences des arguments de f sont liées. 
0 


PROPOSITION 2 


L'appel EPR (Cf ?-) pourra être interprété semi~itérativement 
si, à l'entrée dans APPLY, nous avons les conditions simultanées 
1) stack(top) = evlis4 
2) stack(top - 2) 


3) stack(top — 4) 


£ ou une fonction standard 


f 
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La condition !) garantit que c'est an, dernier argument de g qui est 
traité par EVLIS. 

La condition 2) garantit la sûreté de l'interprétation semi-itérative. 
La condition 3) garantit que l'appel (Cf ?-) est en position post- 


récursive enveloppée. 


PREUVE 


1) Par construction, le dernier argument de g est traité par 
evlis3 qui rend l'état de pile 
evlis4:built:g:a{APPLY} 
2) Par construction, hdexp = g a été placé par le passage a 
EVAL de (gal... an). 
3) Si (£ ?-) est le premier appel récursif de f, alors 
a = apply3:f:env, :P 


Si (£ ?-) n'est pas le premier appel récursif de f, alors 


a = apply4:f:evlis4 
Au premier appel (gal ... an), nous avons, à l'entrée de 
APPLY, l'état de pile 
al = apply3:f:env :a{APPLY} 
Si l'évaluation des arguments al, a2... an-] se termine, 
nous aurons, avant l'évaluation du dernier argument 
(£ ?-) de g, l'état de pile 
a2 = evlis4:built:g:al{APPLY} 
et stack(top - 4) = f. 
A la sortie de APPLY nous aurons l'état de pile 
{APPLY }progn:apply4:f:02 
le lancement correspondant au premier appel récursif 
Cf ?-) donne donc 
apply4:f:evlis4:built:g:apply3:f:env, :a{APPLY} 
Tous les k appels ultérieurs EPR de f verront l'état 
de pile 
evlis4:built:g:apply4:f evlis4:built:gsapply3:f:env, :afAPPLY} 


k-1 fois 
pour lequel stack(top - 4) = f 


c 
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PROPOSITION 3 


Si la fonction f se termine, les continuations (1.e. les 


appels en attente de la fonction g) seront effectuées au 


retour. 


PREUVE 


Le dernier appel de (Cf ?-) laissera l'état de pile 
retcont:apply4:f:evlis4:built:g:f 

APPLY4 dépilera alors f et redonnera le contrôle à EVLIS4 

qui donnera lui-même le contrôle à APPLY avec l'état de pile 
B{APPLY} avec exp = g 

et la liste des arguments évalués dans arglist. 


L'environnement initial de f sera restitué lorsque B sera 


redevenue 

apply3:f:env, :a 
dans les mémes conditions que pour les cas NPR et CPR. 
L] 


Le délai à l'exécution correspondant à cette classe est 
1) pour tous les appels : un test vérifiant que l'élément en sommet 


de pile est l'adresse EVLIS4 


2) pour les appels EPR : deux tests en cascade. 


Ce délai est compensé par la non préservation des environnements dans 


les cas reconnus sûrs. 
L'économie de pile ainsi réalisée est proportionnelle 
1) au nombre d'appels EPR successifs 


2) au nombre des arguments de la fonction ainsi appelée. 


216 


am ts mm i eS ie SE i el mi væ d m m a a D a a pi ii i S e iil 


Examinons l'évolution de l'état de la pile dans le cas d'une fonction 


comportant des occurences mixtes d'appels NPR et EPR 


(DE DELETE (X L) CCOND 
CCNULL L) NIL) 
CCEQUAL X CCAR L)) 
(DELETE X CCDR L))) 
CT CCONS CCAR L) (DELETE X CCDR L)))))) 


Soit l'appel 
(DELETE 'A 'CA BAA C D)) 


Nous aurons au premier appel l'état de pile 


x 0 {APPLY} 
sulvi de 

al = apply3:delete:enVjelete: 20 { PROGN } 
Avec L= (ABAACD) 


l'état de la pile demeure stationnaire, 


Avec L (BAAC D) 


li 


Nous obtiendrons 


a2 


evlis4: (B):cons:al{APPLY } 


(A AC D) 


Avec L 


Nous obtiendrons 


a3 = apply4:delete:a2{APPLY} 
Avec L = (C D) 


Nous obtenons 


a4 = evlis4:(C):cons:a3{APPLY} 
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Avec L = (D) 
nous obtenons 


a5 


evlis4:(D):cons:apply4:delete:a4 


Arrivés en fin de la liste L, nous avons l'état de pile 


(D) :cons:apply4:delete:evlis4:(C):cons:apply4:delete:evlis4: 


(B):cons:apply3:delete:env :a0 {EVLIS} 


delete 


On observera que l'environnement envers n'a été préservé qu'une seule fois. 
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7.5.7 FONCTION D'ACKERMANN : APPELS NPR et EPR 


Examinons dans le cas de la fonction d'Ackermann le comportement de 


l'interprète VLISP en termes de préservations et restitutions d'environnements. 


Nous compterons 2 unités de temps (us) pour chaque opération empiler 
et déptler (1 pour l'extraction de la donnée, | pour la modification de pointeur 
de pile). Un appel non post-récursif dépile et empile l'environnement et la 


lambda-fonction. Un appel EPR dépile et empile la lambda-fonction. 


En général, pour une fonction à m arguments, 


un appel non post-récursif coûtera : 4 + 4.m us 
un appel NPR coûtera : 0 us 
un appel EPR cotitera = 4 us , coût constant, 


non dépendant du nombre d'arguments. 


Dans le cas de la fonction d'Ackermann, le nombre total c(x , y) d'appels 
récursifs est donné jusqu'à y = 3 par (SUNBLAD 1971). 
Nous compléterons ces données en différenciant pour y = 1, 2, 3 le nombre 


d'appels NPR et EPR. L'appel initial n'est évidemment pas compté. 


c(l , y) = 2y + I 
npr(l , y) = y+ I 
epr(l , y) = y et npr -~ epr = 1 


c(2 , y) = 2y” + Jy + 4 
npr(2 , y) = y° + 4y + 3 


epr(2 , y) = oF + 3y + | et npr - epr = y + 2 
c(3 , y) = 2097 kedd pya 
` ) 
npr(3 , y) = (27710 A) "ØDE y + 3 


epr(3 , y) = 0 Ly = 3.27* + 2y + 8 et npr — epr = 2943 ~ (y + 4) 
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epr(x , y) 
0 ] 2 3 4 5 6 
] 0 ] 2 3 4 5 6 
2 l 5 11 19 29 41 55 
3 |5 47 257 1187 5093 21095 85865 
npr(x , y) 


Ces données permettent le calcul du gain obtenu par les interprétations 

itératives et semi-itératives. 

Ainsi, sans ces interprétations 

2 126 784 us 
343 460 us 


CACK 3 6) coûtera (epr + npr).12 


et avec ces interprétations epr.4 
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7.6.- COMPILATION D'APPELS POST-RECURSIFS 


Les optimisations que nous avons proposées en ce qui concerne les 
interprètes ont, appliquées cette fois aux traducteurs, fait l'objet de 
nombreuses études (RISCH 1973, KNUTH 1974, LASSAGNE 1975, DARLINGTON 1976, 
AUSLANDER 1976, DERANSART 1977, BIRD 1977). 


Il serait naturel d'espérer que les compilateurs LISP aient incorporé 
ces méthodes d'optimisation. Aussi il est surprenant de constater qu'il n'en 
est rien, en ce qui concerne par exemple le compilateur NCOMPLR de MACLISP 
(GOLDEN 1970, ROSEN 1972, WHITE 1976) 77. Ce dernier, quoique fort réputé, 
produit du code trés inférieur en performance, à l'interprétation réalisée en 


VLISP, en ce qui concerne la préservation des environnements et des continuations. 


Cette comparaison va être menée à travers plusieurs exemples, dans 
lesquels nous noterons pile = a l'empilement de a, a = pile , le dépilement 
dans a, et P le pointeur de pile. Al, A2, A3, etc. seront comme à l'accou- 


tumée des registres. 


Exemple | : cas NPR 


(DE REV CL P) CCOND 
((CDR L) (REV CCDR L) CRPLACD L P))) 
(T CRPLACD L P)))) 


Le code produit par NCOMPLR sera : 


REV = pile + Al; pile = A2 ; 
A3 + (CDR Al) ; 
st A3 = NIL alors vers G2 fst 


D SSeS ee a es pile = A3 ; CCDR Al) <- A2; 
Jesse See A2 + Al ; Al = pile ; 
nn ae ERE ree REV ; vers Gl ; 

G2 = (CDR Al) + A2 ; 

Gl = P + P - 2 ; derece 


(1) Le compilateur de LISP 1.6 (LONDON 1971, QUAM 1972, SAMET 1975) est å cet égard 
tout aussi déficient. Nous n'avons pas eu l'occasion de tester le compilateur 
{NTERLISP (TEITELMAN 1976). 


ae ee es ee — dt 


oo où kN ue e e pee fe SS pr ear 


On constate que NCOMPLK 


I) préserve inutilement l'environnement (les valeurs 
de Al et A2) à chaque appel 

2) empile et dépile (CDR Al) sans aucune raison, 
aux lignes 2 et 3 

3) ne perçoit pas la nature post-récursive de l'appel 
de REV en ligne 4, en y empilant inutilement une 


continuation. 


L'interprétation réalisée en VLISP de la fonction REV sera 


équivalente au code 


REV = A3 + (CDR Al) ; 
st A3 = NIL alors (CDR Al) + A2 ; derec fst 
(CDR Al) + A2 ; 
A2 + Al ; Al < A3 ; vers REV 


dans lequel tant l'environnement que la continuation sont 


abandonnés, l'appel de REV étant NPR. 


n "e w ee ma am ee ee ee ee eee ee ee ee 


(DE APPN CX Y) CCOND 
CX CCONS CCAR X) CAPPN CCDR X) Y))) 
CY))) 


Le code produit par NCOMPLR sera 


APPN = pile = Al ; prle = A2 ; 
st Al = NIL alors vers G2 fst 
Al + (CDR Al) ; 


ree APPN ; 
A2 + (CAR pile [P - 11) ; Al + CCONS A2 Al) ; 
vers Gl ; 

G2 = ALAL; 

Gl = P«P- 2 ; derec 


On constate que les valeurs de Al et A2 sont inutilement empilées 


à chaque appel, dans un cas manifestement EPR. 
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En VLISP, l'interprétation effectuée sera équivalente au code 


APPN = a7 AL = NIL a/ore Al © A2 3 deree fer 
pile < CCAR Al) ; 
ree APPN 5 
A2 = pile ; Al + CCONS A2 Al) ; 


derec 


où l'environnement (en particulier la valeur de A2) n'est pas 


préserve. 


(DE LIN CL R) CCOND 
© CCNULL L) R) 
CCATOM L) CCONS L R)) 
(T CLIN CCAR L) CLIN CCDR L) RDDDD) 
Le code produit par NCOMPLR dans le cas d'occurences simultanées 


d'appels NPR et EPR, est ici particulièrement déficient 


LIN = pile = Al ; pile = A2 ; 
st Al # NIL alors vers G2 fst 
Al + A2 ; vers Gl ; 
G2 = app ATOM; st Al = NIL alors vers G4 fst 
| --------- Al + A2 ; A2 + Al ; 
Al + CCONS pile [P - 1] A2) ; vers Gl ; 
G4 = Al + CCAR pile [P - 11) ; prle = Al; 
Al + CCDR pile [P - 1D ; 


des nec. LIN 
A2 + Al ; Al € pile ; 
3 aa Poe LIN 3 
Gl = P&P - 2 ; derec 


On y constate en ligne I des manipulations erratiques de registres, 
l'empilement inutile de Al et A2 lors de l'appel EPR en ligne 2, 


la non-reconnaissance du caractére NPR de l'appel en ligne 3. 
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L'interprétation de LIN en VLISP sera équivalente au code 


LIN = sú Al = NIL alors Al + A2 ; derec fst 
pile = Al ; app ATOM ; 
st Al z NIL alors Al = pile ; Al « (CONS Al A2) ; derec for 
pile [P] + CCAR pile [F]) ; Al + CCDR Al) ; 
rec LIN ; 
A2 + Al ; Al © prie ; vers LIN 


où l'environnement (en particulier la valeur de A2) n'est pas 
empilé inutilement, et dans lequel le caractère NPR de l'appel 


(LIN CCAR L) ... ) est interprété comme un branchement. 


En général le compilateur MACLISP ne traduira correctement par un branchement 


que 


1) les appels NPR de fonctions à 0 arguments 
2) les appels NPR triviaux non imbriqués dans une expression 


conditionnelle. 


Ces indications ne visent naturellement pas à démontrer que NCOMPLR jouit d'une 
réputation usurpée, mais tout au contraire à lui porter une critique positive 
concernant certains de ses aspects peu probants. 

Il est clair que l'examen plus attentif des schémas de programmes permet 
d'améliorer sensiblement la qualité des compilateurs LISP pour la traduction 
d'appels récursifs : ainsi le compilateur construit par Jérome CHAILLOUX pour 
VLISP 10 (CHAILLOUX 1977) compile correctement les occurences d'appels NPR. 

La détection statique d'appels NPR et EPR est relativement simple : nous 


donnons à l'appendice 9 en VLISP les algorithmes de détection. 


me. 
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CHAPITRE 8 


CONCLUSION, REFLEXIONS, PROJETS 


8.1.7 ENVIRONNEMENT-SYSTEME ET SUR-LANGAGES EXTERNES 


Nous avons centré notre étude sur VLISP en particulier et les 
interprétes LISP en général, sur leurs descriptions, leurs implémentations, 
leurs optimisations. En VLISP comme pour d'autres versions de LISP bien 
des problémes ne concernant pas directement l'interprétation sont posés, 
et reçoivent des solutions partielles qui font à l'heure actuelle l'objet 


d'actives recherches. 


C'est le cas 


° des problèmes d'allocation d'espaces de mémoire réelle ou 
virtuelle (STEELE 1974, BAKER 1977b) et d'influence des 
décisions d'allocation sur la formation des listes (CLARK 
1976) {77 


° des différents types proposés de garbage-collection incré- 


mentale (BISHOP 1975, STEELE 1975, DEUTSCH 1976, BAKER 1977c) 


. des projets de processeurs spécialisés, connus å présent sous 
le nom de machtnes-LISP (BARBACCI 1971, DEUTSCH 1973, 
GREENBLATT 1974 , ATTARDI 1976). 


Malgré leur grand intérêt, ces questions plus orientées vers l'environnement- 
système de l'implémentation de LISP que sur son interprétation ne seront pas 


abordées dans cette étude. 


(1) Un résultat inattendu de (CLARK 1976) indique que les cellules d'une 
liste tendent à être physiquement rapprochées en mémoire. Ce phénomène 
est dû à la proximité temporelle de leur création, de façon relativement 


indépendante d'un mode particulier d'allocateur et de choix de page. 
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A l'autre extrême, nous ne nous attacherons pas davantage aux tentatives de 
surimposition à LISP d'un sur-langage externe, d'apparence ALGOL, tels que 
MLISP (SMITH 1970, 1973), CLISP (TEITELMAN 1973), ou CGOL (PRATT 1976). Leur 
nécessité n'est pas apparente. En effet, ces sur-langages dépendent d'une 
hypothèse que l'expérience ne vérifie pas : la difficulté de lecture et 
d'écriture de LISP comme langage externe. Il se révèle que l'extrême structu- 
ration de LISP en facilite au contraire l'écriture, particulièrement en 

mode interactif. Les réels problèmes que pourraient poser sa lecture sont 
résolus à la satisfaction générale par l'usage des utilitaires LISP dits 

de PRETTY-PRINT (BOYER 1973, GOLDSTEIN 1973). | 

La pratique quotidienne de VLISP en fait pour sa part un large usage. 

De surcroît, les sur-langages proposés ne compensent en aucun cas un avantage 
considérable offert par LISP, que fait observer (SANDEWALL 1976a) : la visua- 
lisation aisée tant en lecture qu'en écriture, de structures de données et de 
programmes, de complexité arbitraire. Peu de langages permettent ainsi la 
représentation externe de données structurées quelconques. 

Notre notation par filtres vise explicitement à exploiter cet avantage / 
décisif, pour rendre les implémentations plus explicites et plus rapidement 


réalisables. 


=. Nous avons choisi de conclure cette étude par l'examen des outils 
de mise au point et de développement de programmes, et de l'intégration 


de ceux-ci aux interprètes LISP. | 


Les observations et les suggestions qui vont suivre sont directement issues 

du développement et de l'utilisation de VLISP à l'Université Paris 8-Vincennes, 
ainsi que de la pratique de MACLISP au laboratoire d'Intelligence Artificielle 
du M.I.T. | 
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8.2.1.- INTERPRETATION EN MODE STEPPER 


Un instrument essentiel de mise au point est, en VLISP et MACLISP, 
le mode d'interprétation connu sous le nom de stepper. | 
Celui-ci est une généralisation de la situation de dialogue inhérente à 
LISP dans son usage interactif. Le mode stepper réalise un calcul surveillé, 
en pas à pas à grain variable. 
Le grain,ou unité de dialogue, est essentiellement l'appel de procédure 
introduit au terminal, et la réception de la valeur retournée par cet 
appel. | | 
En mode usuel, 1° utilisateur n'intervient pas entre ces deux événements 
qui se succèdent en général très rapidement. 
Le mode stepper, au moyen d' interruptions hardware ou programmées, permet 


de subdiviser ce grain en unités plus élémentaires. 


Deux questions doivent être alors considérées 
@ quand doivent avoir lieu ces interruptions? 


e que se passe-t-il pendant ces interruptions? 


_La première question concerne la détermination du grain. On peut en distinguer 
trois niveaux | | 


1) le premier est réalisé par l'utilitaire LISP popularisé par INTERLISP : 
sous le nom d'ADVISE (TEITELMAN 1974, p. 19.1-10). Les divers modes bien 
connus de traces ou de breaks en sont des variantes. 

En mode ADVISE, le grain est réglé sur les régions textuelles du programme : 
sa division naturelle en LISP en procédures séparées. 

L'interruption se produit à l'appel et au retour d'une fonction définie. 

Une procédure est interprétée en mode ADVISE si l'utilisateur la cerne 


d'interfaces d'entrée et de sortte. 
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Soit la fonction 


f = (A, !- corps-de-f) 


l'appel 
CADVISE f E rees 2 interface-de-sortte) 
transforme f en 


f = (à, !- tnterface-d'entrée 

FØNSE (LET (Crésultat CPROGN corps-de-f))) 
interface-de-sortte 
résultat)) 


Le corps-de-f, ainsi que les interfaces d'entrée et de sortie sont des suites 
d'expressions LISP. 

La transformation est bien entendu reversible, par la commande duale UNADVISE. 
Ainsi, à chaque appel de Fe , l'interface-d'entrée est d'abord exécuté, 
puis le corps-de-f, puis enfin l'interface de sortte. 

La valeur retournée par l'appel de f en mode ADVISE sera cependant la même 


qu'en mode normal. Cette extension est conservatrice : aucune information 


n'est perdue, f en mode ADVISE réalise le même calcul qu'en mode normal. 


2) Le second niveau est le mode d'interprétation connu en MACLISP sous le 
nom d'EVALHOOK (MITLSPR 1975). | 

En mode EVALHOOK, le grain est réglé sur les modules internes de 
L'tnterpréte. 

L'interruption se produira lors du passage dans un de ces modules, EVAL 
dans le cas présent. 

A chaque entrée et sortie du module EVAL, une fonction d'interruption 
définie par l'utilisateur est exécutée. Le mécanisme repose sur l'existence 
simultanée d'un module interne EVALHOOK de l'interprète MACLISP, et d'une 
C.valeur de la vartable EVALHOOK. 
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En voici le principe, décrit par la transcription en VLISP des modules 


internes EVAL, EVALHOOK et HOOK. 


(DE EVAL CE) 
CIF EVALHOOK 
CLET CCEVALHOOK NIL) CF EVALHOOK)) 
CF E)) 
CEVAL-INTERNE E ))) 


CDE EVALHOOK CE HOOK-FONCTION) 
(LET CCEVALHOOK HOOK-FONCT ION) > 
CEVAL-INTERNE E))) 


(DF HOOK CE) 
(LET CCEVALHOOK 'fone-tt)) 
CEVAL CCAR E)))) 


Un appel 
(HOOK une-expresston-e) 


provoquera, à chaque passage dans EVAL, le lancement de la fonction 
d'interruption fone-tt, définie en LISP par l'utilisateur. 
En voici un exemple, réalisant une trace classique de 1'évaluation de 


l'expression e 


CDE fonc-it CE) 
(PRINT "FORME: E) 
(PRINT 'VALEUR: CEVALHOOK E 'fone-tt))) 


La variable EVALHOOK joue le rôle d'un masque d'interruptions : le mode 
EVALHOOK est désarmé pendant l'interprétation de la fonce-1t qui fait 
indirectement appel à EVAL. 


EVALHOOK, de même qu'ADVISE, est une extension conservatrice. 


3) Enfin, le troisième niveau de détermination de grain est le mode d'inter- 
ruption réalisé par le programmeur au terminal, par la frappe d'une touche 


d'interruption, jouant pour le calcul un rôle analogue à celui joué par les 


macro-caractères (cf. §6.2.5.2) pour le flot d'entrée-sortie. 
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Une fonction LISP définie par l'utilisateur et associée au caractère d'inter- 
ruption est lancée aussitôt que la touche du clavier de terminal correspondant 
à ce caractère est frappée. Le grain est alors réglé par le comportement du 
programmeur au terminal. 

L'interruption n'est plus synchronisée à une procédure ou à un module interne 
de l'interprète, mais est déterminée par l'appréciation subjective du program- 
meur des necessités d'intervention entre les étapes du dialogue. 

Ce mode est totalement dépendant de l'environnement-système de l'interprète, 


en particulier de la gestion des tampons d'entrée. 


À notre seconde question : «que se passe-t-il pendant/à l'occasion 
de ces interruptions?» , la réponse est multiple. 
Un programmeur peut se définir ainsi diverses traces, des boucles-racines 
de consultation et de modification, divers types de calculs surveillés, depuis 
l'exécution d'assertions jusqu'au lancement de procédures de gestion de base 
de données. 

Les limitations de ces possibilités ne sont pas apparentes. C'est 
leur existence et leur utilisation intensive, en LISP plus qu'en aucun 
autre langage qui fait problème et nous incite à en rechercher un principe 
unificateur. Ce principe nous semble offrir une alternative, une voie peut- 
être complémentaire, et moins restrictive, aux préoccupations actuelles, 


profondëêment normatives de méthodologie de la programmation. 
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8.2.2.- REPRESENTATIONS, COMPREHENSION, MISE AU POINT 


Que signifie l'énoncé «concevoir un programme» ? 
Voici une réponse partielle issue de la pratique de la programmation en 


Intelligence Artificielle : concevoir une programme, c'est en mettre au point 


(1) 


un autre déjà connu (SUSSMAN 1975) . Ce point de vue a été repris récemment 


dans une perspective plus théorique par (DERSHOWITZ 1976). 


Le point de vue de la mise au point implique qu'en un certain sens, un 
programme n'est ni juste ni faux. Ni juste, car toujours susceptible d'être 
modifié, amélioré ou étendu, à mesure que surgissent de nouveaux besoins ou 
que s'approfondit la compréhension du probléme dont le programme est le 
modèle. Ni faux, car toujours susceptible d'être tracé et édité. 

Ainsi le point de vue de la mise au point met l'accent sur l'ubiquité des 
modifications de programmes, et donc des modifications de représentation 


et de compréhension. 


(1) Cette réponse récursive encourt bien entendu le risque de régression 
infinie, sauf à lancer des questions supplémentaires : quelles sont 
les données observables qui sont retirées de l'expérience de la 
programmation? Que peuvent-elles nous apprendre sur nos propres 
processus de pensée, et sur leur génése? 
Il est douteux que des réponses convaincantes soient à attendre 
dans 1! immédiat à ces questions classiques, faute de données suffisantes. 
L'immense intérêt de 1' expérience. de la programmation nous paraît 
résider moins dans l'exportation à la psychologie de métaphores mécanistes 
comme le souhaite (MINSKY 1970, p. 207) que dans la possibilité de 
mise en place de Laboratoires conceptuels, permettant l'observation 
et l'expérimentation directes sur les processus intellectuels. 
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UNE EXPERIENCE DE COMPREHENSION 


En avril 1977, nous avons tenté de repérer concrétement quelques unes 
des difficultés de la compréhension de programmes, 4 travers une expérience 
informelle menée sur un cas trés simple. 

A plusieurs programmeurs de l'Université Paris 8 et de l'Université Paul 
Sabatier, tous trés familiarisés avec VLISP et son implémentation, nous 


avons soumis la fonction suivante, avec pour mission d'en découvrir 1'tntentton. 


(DE SKE CL R) CCOND 
(CATOM L) NIL) 


2 ----------------- CCMEMQ L R) T) 
À = CCSKE CCAR L) CCONS L R)) T) 
4 = (T (SKE (CDR L) (CONS L RDD) 


L'expérience consistera 4 


e présenter la fonction sans autre commentaire et laisser 
les sujets réfléchir quelques minutes 

e compléter cette fonction par des thèmes présentés 
successivement, certains trës intuitifs, d'autres plus 
formels,éléments de connaissance susceptibles d'en 


faciliter la compréhension. 


Thème 1 : L'appel initial de SKE est 


(SKE une-Ztste-L NIL) 


Thème 2 : Les deux arguments de la fonction standard MEMQ peuvent être 


des listes 


Thème 3 : SKE décèle des effets de bord, antérieurs à son application 


Thème 4 : L est une liste circulaire 
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Thème 5 : Soit x et y deux cellules de liste, et la relation 
x € y 
si y = Ce: !-) ou Cl- : x) 
ou 
si x < (CAR y) ou x < (CDR y) 


Une liste est non-ctreulatre si, pour deux de ses cellules 


x et y on n'a jamais simultanément 


L € y et y € X 


Un seul des sujets participant à l'expérience découvrit la destination de SKE 
dès la présentation du thème 3. La présentation du thème 5 fut nécessaire à 
l'un d'entre eux. Tous les autres sujets donnèrent la réponse correcte lors de 
la présentation du thème 4. 

Quels furent les éléments observés? 

Le thème 3 indique déjà nettement que L ou une de ses sous-listes est circu- 
laire : une liste circulaire doit être construite par la mise en jeu des 
primitives RPLACA et RPLACD. Le premier sujet ayant décelé l'intention de SKE 
programmait depuis quelques jours une routine d'impression élégante de listes 
circulaires. 

Le thème 4 est positif, le thème 5 est négatif : il indique ce qu'une liste 
circulaire n'est pas. Le sujet ayant attendu le thème 5 pour livrer une 
réponse correcte admit volontiers qu'après l'avoir considéré un instant, il 


perdit de vue le fait que la fonction SKE est booléenne. 


Tous les sujets firent cependant plusieurs observations pertinentes au cours 
de l'expérience. La clause 4 fut déclarée par tous itérative, opérant le 
balayage de L dans le sens des CDRS, et la clause 3 récursive, balayant L 

dans le sens des CARS. L'analogie avec le schéma de la fonction EQUAL fut 
unanimement constatée. 

Le thème 1 semble avoir provoqué un brouillage de représentations : la 
variable R fut bien reconnue comme un accumulateur, la représentation statique 
de son contenu a fait, de l'avis général, probléme. Une fois l'accent 

mis sur l'aspect dynamique de sa construction, la destination de R est devenue 


pour chacun évidente. 
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Qu'en conclure ? 


L'expérience a mis en valeur des difficultés conceptuelles liées å des 


interférences de représentations 


(1) 


1) interférence entre le schéma récursif de SKE et la 
représentation itérative qu'entraine la mise en jeu d'un 


(1) 


accumulateur 


2) interférence entre construction et rétention. CONS construit 
une nouvelle structure, MEMQ teste à la clause 2 l'identité 
des deux listes : L la liste courante examinée, et une sous- 
liste de L recueillie dans R à une étape précédente du 
balayage. 

Cette interférence a fait perdre de vue à nos sujets que 
MEMQ utilise EQ, qui teste l'identité physique de deux 
objets, indifféremment atomes ou listes, par comparaison 
d'adresses. Ce test d'identité physique a rendue vaine la 


tentative d'analyse,par nos sujets, de la structure interne 


des sous-listes de R. 


De plus une interférence de représentations spatiales a dû 
jouer : entre le caractère arborescent de L, impliqué par 
le schéma de type EQUAL de SKE, et le caractère linéaire 


de R, construite par CONS successifs. 


3) enfin interférence de type manipulatoire : L est décomposée 
en (CAR L) et CCDR L) au cours du balayage. Mais L n'est pas 


décomposée lors de sa composition par CONS dans R. 


La variable R retient les CDRS de toutes les sous listes de L, mais R 
est testé dans la condition d'arrét (clause 2). Cette it Tirs Ton 
d'accumulateur en situation récursive s'écarte ainsi de celle de 
(MOORE 1975) ot le méme probléme de la coexistence de représentations 
itératives et récursives est posé dans un contexte de démonstration 
automatique. 
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Toutes ces difficultés conceptuelles indiquent que le probléme principal de la 
compréhension et de la mise au point de programmes est probablement celui des 
interférences de représentations. 

Il est peu douteux que la lecture et la compréhension de programmes mettent en 
jeu des répertoires de représentations trés variés (en premiére approximation : 
spatiales, manipulatoires, iconiques, illocutionnaires, discursives, relation- 
nelles, régulatrices, temporelles, déclaratives, impératives), répertoire dont 
l'acquisition par les programmeurs constitue un mécanisme encore à peu prés 
en. . Sans vouloir tenter d'approfondir ici le problème de l'acquisition 
de ces répertoires, il n'est pas du tout établi que la lecture et la compréhen- 
sion mettent en jeu les mêmes représentations que celles qui président à la 
construction des programmes. Des études récentes sont cependant fondées sur 

une telle prémisse | 

(RICH 1976) fait l'hypothèse que la compréhension d'un programme est réductible 
à sa compilation en plans, qui décrivent de façon procédurale ā la fois sa 
structure et ses intentions. Ce point de vue, impliquant un programme déja 
construit, ne nous paraît pas pouvoir rendre compte des difficultés, impasses, 
interférences et modifications de perspective qui sont à l'origine des erreurs 
de programmation. 

Le système PHENARETE (WERTZ 1976) identifie la compréhension d'un programme 
LISP, correct ou non, à la donnée de plusieurs propositions du même programme 
modifié et amélioré dans la mesure du possible. Cette dernière approche, très 
bien adaptée à la maintenance de programmes, nous paraît plus fidèle a la 
réalité de la programmation, en admettant l'existence simultanée de représentations 
multiples. 

Ces études opèrent sur des textes de programmes déjà existants, et mettent en 


jeu à divers degrés, des procédures de traduction. 


Nous nous écarterons de ces approches en ce qui concerne le problème de la 
mise au point qui nous paraît être de nature essentiellement interprétative : 
concernant moins un texte statique, qu'un ensemble très mal connu de compor- 


tements intellectuels. 


(1) La mise à jour de ce mécanisme d'acquisition, en dehors de son intérêt 
intrinsèque considérable, est d'une importance critique pour la pédagogie 
de la programmation. 
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Dans cette perspective, l'occurence d'erreurs en programmation ne serait pas 
tant un mal à exorciser, qu'une manifestation extrême d'un continuum de 


comportements et de représentations qui sont ceux des programmeurs. 


Nous avons besoin d'un instrument qui nous permette d'observer ces compor- 
tements. Les données recueillies par un tel instrument peuvent nous permettre 
d'inférer la structure interprétative qui manipule, modifie et combine ces 
représentations. | 

Un système d'aide à la mise au point, particulièrement en situation inter- 
active, peut fournir, de surcroît à sa fonction d'aide à la programmation, 
cet instrument d'observation et d'enregistrement de l'activité d'un 


programmeur. 


8.3.- PROJETS : VERS UN SYSTEME D'AIDE A LA MISE AU POINT 


Le prolongement naturel de notre travail consacré à VLISP, 4 sa 
définition, à ses extensions, à l'implémentation de ses interprètes est 
un tel système d'aide au développement et à la mise au point, que nous 
avons baptisé VISION. 

Ce travail est en cours, nous ne ferons ici qu'en esquisser les 


motivations et quelques unes de ses particularités techniques. 


8.3.1.- LISP ET VISION 


L'expérience décrite au §8.2.3 met en lumiére les difficultés liées 
aux interférences entre représentations. Un systéme d'aide 4 la mise au 
point doit permettre de faire coexister des représentations multiples, 


et doit donc fournir des tnterfaces entre ces représentations. 
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Par ailleurs, l'expérience de la programmation en LISP en mode interactif 
indique que le concept de programmation n'est pas homogéne, mais rassemble 
un grand nombre d'activités et de représentations de programmes : traces, 
évaluations simples et surveillées, éditions, lecture et écriture de com- 
mentaires, méta-évaluations, construction et test de jeux d'essai, écriture 
et réorganisation de code, prettyprint, cross references, pas å pas. 

La frappe des commandes qui ordonnent la succession de ces activités forme 
la majeure partie d'une session en mode interactif. En un sens, un programme 
n'est rien d'autre que l'ensemble des points de vue et des structures 
internes qui sont mises en jeu par ces activités. Chacune de ces activités 
composante standard d'un environnement LISP, est une structure interprétative 
particulière, que nous nommerons v7ston. 

Nous avons pu observer que LISP, langage interprété, est pour une 
grande part un outil de construction d'interprétes. Ces interprètes sont 
également des activités ou visions, et peuvent être défints par un utilisateur 
du système, de la même façon que LISP peut être étendu par la définition de 


nouvelles fonctions EXPR, FEXPR et MACRO. 


LISP contient en germe le concept de vision et de représentation 
multiple : de par son environnement et les très nombreux utilitaires qui 


complètent l'interprète-noyau (SANDEWALL 1976b), de par également l'utili- 
(1) 


sation intensive de P-listes . Comme le note (BALZER 1972), l'utilisation 


de P-listes permet de retarder indéfiniment le choix de représentations 
concrètes de données. Cet aspect encourage l'expérimentation, en donnant au 
programmeur l'impression justifiée que les décisions d'implémentation qui 


sont prises ne sont pas irrévocables. 


(17 Statiquement, une P-liste est un vecteur indexé par référence, mais 
de domaine indéfini. Une P-liste peut être considérée comme un filtre 
élémentaire très rigide, ou, plus traditionnellement,comme un enregis- 
trement dont les champs sont définis dynamiquement, sans déclaration 
préalable. 
Le système PHENARETE (WERTZ 1976) et les programmes LISP dits data-driven 
(SANDEWALL 1976a) en font un très large usage, en mettant en jeu des 
appels de procédures indirects par rapport à une base de donnée. 
Les contextes de QAk et CONNIVER sont des généralisations des P- listes. 
Dynamiquement, une P-liste peut être considérée comme une construction 
de type SELECTQ, dans laquelle des cas supplémentaires peuvent être 
ajoutés ou retranchés à l'exécution. 
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Ainsi un appel : 
(GET un-objet un-attrtbut) 
peut se reformuler : 
quelle est la nature de l'objet considéré sous la vision de l'attribut? 


ou encore, sachant qu'au cours d'une session, l'interrogation est lancée dans 
le contexte d'une vision particulière : 


question-posée dans la-vision-courante : qu'est-ce que l'objet sous 
La-vision-attribut? 


De même l'appel : 


CPUT un-objet une-valeur un-attribut) 


peut se reformuler : 


commande-émise dans la-vtston-courante : attacher-à l'objet la-valeur 
sous la-viston-attrtbut. 


-r FEE re oe oe oe a ee a NN De ee ee ee ee ee QD ee ee ee ee ee ees ee ee es ee 


Dans les environnements LISP traditionnels, les visions standard : 
éditeurs, traces, interprétes etc. sont isolées, et appelées successtvement 
au cours d'une session. En revanche, le systéme VISION admet la coexistence 
simultanée de visions, qui, généralisations des fermetures étudiées aux 
$3.7 et 6.2.11, sont des fermetures d'activité. Un programmeur réactivant une 
vision la retrouve dans 1'état de sa derniére activation (macros de commandes, 
état de terminal, environnement), et peut ainsi travailler simultanément dans 
plusieurs visions, standard ou définies : une fonction pourra ainsi être 
interprétée par LISP, évaluée par un interprète défini au cours de la session, 
prettyprintée, éditée et tracée, chacune des visions courantes, standard ou 


définie pouvant utiliser des informations recueillies par les autres. 
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Le problème principal, tant de définition que d'implémentation est 
celui de la communication entre visions. Statiquement, chacune d'elles est 
implémentée comme une base de donnée de type CONNIVER. Un objet est considéré 
comme a priori défini dans toutes les visions courantes. En effet, le système 
VISION introduit la notion d'objet à type multiple : un objet est défini par 


l'ensemble de ses types i.e., ses définitions dans chaque vision. Un tel 


objet pourra être aussi bien 


e un objet LISP : atome, liste ou expression évaluable 
° un calcul : sous forme de traces et de conservation des liaisons 
° un démon au sens CONNIVER : procédures lancées par interruption, 


permettant des flashes d'avancement 


et des diagnostics actifs 


° une session attachée à une vision : suite des commandes déjà 
émises, des expressions soumises 
à l'évaluation ainsi que leurs 


valeurs et environnement. 


Une session est, dans le système VISION, considérée comme une donnée. 


La communication entre visions est effectuée par un filtrage généralisant 
celui décrit dans cette étude. En FILTRE, les variables de filtres sont essen- 
tiellement des receveurs, les filtres de VISION mettant également en jeu des 
envoyeurs qui spécifient la vision-origine et ferment la sesston dans le 
message expédié à la vision-destination. Le retour en arrière et la restitu- 
tion d'états de session, connu en INTERLISP sous le nom de UNDO en est trés 


facilité. 


Dynamiquement, chaque vision est implémentée comme une tâche : procédure 
non-terminante dont l'activation et laréactivation sont déterminées par le 

. . t a ! . 
programmeur au terminal, par frappe au clavier d'un caractére d'interruption 


spécifiant la vision-cible. 
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La vision standard principale est une extension de l'interprète VLISP permettant 
la procéduralisation des variables =, 

A chaque variable peut être associée deux classes de procédures dont chacune 
est respectivement activée à L'accès en lecture de cette variable, et à 
l'accès en écriture de la variable par affectation de type SETQ ou par 
lambda-liaison. Ces procédures définies par l'utilisateur sont donc trés 
proches des démons de CONNIVER, mais c'est l'environnement VLISP qui est 

ici la base de donnée dont l'accés régle les activations. 

Cette modification de VLISP s'implémente trés facilement si on admet un 
degré d'indirection supplémentaire à l'accès des C-valeurs des variables. 

Un tel dispositif semble permettre une très grande variété de traces, de 
calculs surveillés mais également de possibilités d'enregistrement : il 
devient très facile d'attacher à une variable quelconque un stream des 


valeurs successives qu'elle peut prendre. 


Une vision standard de méta-évaluation pourra être le système CAN de 


Daniel GOOSSENS (GOOSSENS 1977), actuellement en cours d'implémentation. 


Le système VISION doit naturellement être utilisé au moyen de 
terminaux interactifs visuels, permettant, par un sous-systéme de fenétrage 
(RIEGER 1975) l'affichage indépendant de représentations multiples. Les 
terminaux DATAMEDIA 2500 mis en place à 1'IRCAM (FROST 1977), offrant 
jusqu'à 16 zones (ou bandes) pouvant être gérées de façon indépendante et 


simultanée sont bien adaptées à l'implémentation expérimentale de VISION. 


(1) Cette particularité est une généralisation de la procéduralisation 
des listes proposées par (FISCHER 1972). Dans cet esprit, CONS, CAR 
et CDR pourraient être définis en VLISP comme : 


(DE CONS (X Y) 
(CLOSURE CX Y) CLAMBDA CZ) CIF Z X Y)))) 


CDE CAR CX) CX T)) 
CDE CDR CX) CX NIL)D) 
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Nous pensons que les visions d'édition, classables en deux catégories 
bien distinctes : édition de correctton de code et de commentaire, et édition 
d'extenston tenant compte de l'histoire du développement du programme, doivent 
être défintes, cas par cas, par les utilisateurs mêmes de VISION. Par défaut, 
la vision standard d'édition sera vraisemblablement très proche de l'éditeur 
ETV (FROST 1977) et partagera avec le systéme décrit dans (DONZEAU-GOUGE 1975) 
les possibilités de focalisation et de magnification variable (holophrasting) 


des objets édités. 


L'intérêt principal de l'outil que nous venons de décrire brièvement 
nous paraît résider dans la possibilité qu'il admet (en particulier grâce 4 
la procéduralisation des variables) d'observer et d'enregistrer le comportement 
des programmeurs en situation interactive. Nous faisons l'hypothèse qu'il 
existe des régularités observables dans les cycles de mise au point. Si cette 
hypothése est vérifiée, une certaine prévisibilité du comportement d'un 
programmeur doit permettre au systéme VISION d'anticiper ces comportements, et 
de participer activement au développement du programme. 
En particulier le recueil d'erreurs personnelles dont Donald E. KNUTH conseille 
la constitution (cf. §1.2.3) pourra alors prendre le statut actif d'un systéme 


d'assistance personnelle à la programmation. 


Voici que s'achève notre étude consacrée à un outil réalisé : VLISP, 
par la description d'un outil en formation : VISION. Tous deux partagent ce 
trait commun d'encourager une programmation soumise au minimum de contraintes. 
La multiplicité des représentations inhérente aux interprètes en général et 
à ceux des lambda-langages en particulier a constitué le thème récurrent de 
notre étude : ce thème donne à penser que la mise en place d'un outil de 
programmation, abstrait ou implémenté, n'a de sens que s'il laisse, dans 


toute la mesure du possible, l'imagination intacte. 
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APPENDICE 1 


LISP PUR EN VLISP 


(DE EVAL (EXP ENV) CCOND 
CCATOM EXP) CVALUE EXP ENV)) 
CCEXP :: CQUOTE !EXP)) EXP) 
CCEXP :: CIF !SI 'ALORS !SINON)) 
| ---------- (SELF CIF (SELF SI ENV) ALORS SINON) ENV)) 
2 ~-------- CT CAPPLY CCAR EXP) 
CLET CCEXP CCDR EXP))) 
CIF CNULL EXP) NIL 
3 ------- --- ---- -- - + -- -- - + (CONS CEVAL CCAR EXP) ENV) CSELF CCDR EXP))))) 
ENV)))) 


(DE APPLY CF ARGS ENV) CCOND 

(CATOM F) CIF CPRIMOP F) CEXECUTE F ARGS) 
| =" (SELF (VALUE F ENV) ARGS ENV))) 
Don CCF :: CLAMBDA !LPAR !EXP)) 
3 ---------- CEVAL EXP (LET CCX LPAR) CY ARGS)) 

CIF CNULL X) ENV 
CCONS CCONS CCAR X) CCAR Y)) 

Ds ee CSELF CCDR-X)-CCDR VD) 02) 

CCF :: CLABEL !NOM !EXP)) 
5 =-=- CSELF EXP ARGS (CONS (CONS NOM EXP) ENV))) 

CT CERREUR)))) 


IMPLEMENTATION DE SELF : une modification de APPLY 


use CCF :: CLAMBDA !LPAR !EXP)) 
CEVAL EXP CCONS CCONS 'SELF F) 
(LET CCX LPAR) CY ARGS)) 
CIF CNULL X) ENV 
(CONS CCONS CCAR X) CCAR Y)) 
(SELF CCDR X) CCDR Y)))))))) 
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APPENDICE 2 


SECD LISP PUR 


s,e,id(x):c,d > -> <e(x):s,e,c,d > 
s,e, (QUOTE x)ic,d > + < x!s,e,c,d > 

s,e, CIF x y z):c,d > -> < yizis,e,x:tfic,d > 
nil:y:z:s,e,tfic,d > — <s,e,z:c,d > 
valiy:z:s,e,tf:c,d > — <s,e,y:c,d > 


val:s,e,/am=(LAMBDA (var) corps):ap:c,d > 
> <Q, CSELF:Zam):(var:val):e,corps:(), < s,e,c,d >> 


val:s,e, CLABEL nom CLAMBDA Cvar) corps)=lam):ap:c,d > 
> <Q, CSELF:Zam):(nom:lam):(var:val):e,corps:(), < s,e,c,d >> 


s,e, (f a ...a,Jic,d > > <8,@,a ta t...ia :f'ap'c,d > 


val, :...:val,:s,e,prtmop(p, ):api:c,d > > < Pa (val, s.. eval ):s,e,c,d > 
s,e,1d(x):apic,d > > < s,e,e(x):apic,d > 
—> 


val:s,e, (), < s',e',c',d' >> < val:s',e',c',d' > 
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APPENDICE 3 


FILTRER EN VLISP 


(DE FILTRER (PAT DAT 33 ALIST) (CØND 
(CCFILTRI PAT DAT) 
(WHILE ALIST 
CGR CNUMBP CCAAR ALIST)) 
CSET (CAAR ALIST) CCDAR ALIST))) 
(NEXTL ALIST)) 
T))) 


(MCHAR /s (LAMBDA (©) (LIST °/Zs CREAD)))) 


(MCHAR /! (LAMBDA (33 L) (SETO L CREAD)) 
CIF CATOM L) 
CILE CEO LOST fre 
CLIST SÆT LI 
CCONS °/1 L)))) 


(MCHAR /? (LAMBDA (55 L) (SETQ L CREAD)) 
CIF CATOM L) 
CIF CEC: L. T=) PS 
CLIST TREE 
(CØNS */? L)))) 


(DE INSTANCIER (L 33 X Y) (COND 
CCATOM L) L) 
CCEQ (CAR L) '75) 
CSETQ X (CAPR L)) 
(LIST QUOTE CIF (LISTP X) (EVAL CINSTANCIER x)) 
(SETA Y CASSE X ALIST)) 
CIF Y CCER Y) CEVAL X))))) 
CT CCONS CINSTANCIEP (NEXTL L)) CINSTANCIER L))))) 
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CCE FILTRI (FAT DAT 33 ALIST2 X Y PATE PAT3) (CYND 
CCEQ PAT DAT)) 


(CEQ PAT ‘/1-)) 
(CEQ CCAR PAT) '/!) 
CSETO X CASSG CCALDP PAT) ALIST)) 
CIF X (FILTRI (CDP X) DAT) 
CSETA ALIST CCONS (CONS (CACR PAT) DAT) ALIST)) 
CIF (NULL (CECCP PAT)) T 
CSETO PAT CINSTANCIER (CEDR PAT))) 
CIF CEVAL (CONS 'AND FAT)) T 
(NEXTL ALIST) 
NIL)))) 
CCEQ CCAR PAT) '/?-) 
(NEXTL PAT) 
CIF (NULL PAT) T 
CWHILE DAT CSETQ ALIST2 ALIST) 
CIF CFILTRI PAT DAT) CLESCAPE T)) 
(SETQ ALIST ALIST2) 
(NEXTL DAT)))) 
CCEQ CCAR PAT) ‘/,) 
CSETQ X (CADR PAT)) 
CIF CATOM PAT) | 
CFILTRI CIF CSETQ Y CASSQ X ALIST)) (CER Y) 
C EVAL X)) 
DAT) 
CFILTRI CEVAL CINSTANCIER %)) DAT))) 
CCEQ CCAR PAT) KALT) 
(NEXTL PAT) 
CWHILE PAT CSETQ ALIST2 ALIST) 
CIF CFILTRI (NEXTL PAT) DAT) CLESCAPE T)) 
(SETA ALIST ALIST2))) 
CCEQ CCAAP PAT) '/ 2?) 
(SETQ PAT2 (NEXTL PAT) X CCADR PAT2) Y CASSO X ALIST)) 
(IF Y (FILTRI CAPPENL (CCR Y) PAT) DAT) 
CCOND CCNULL PAT) 


(SETQ ALIST (CONS (CONS X DAT) ALIST)) 
CIF (NULL (CDDP PAT2)) CLESCAPE T)) 
(SETA PAT CINSTANCIER (CDDR PAT2))) 
CIF CEVAL (CONS AND PAT)) T (NEXTL ALIST) NIL)) 
CT CSETG PAT3 (LIST X) ALIST ( CONS PAT3 ALIST) 
ALIST2 ALIST FAT2 (CDDR PAT2)) 
(WHILE DAT 
CIF COR (NULL FAT2) 
( EVAL CCONS ‘AND CINSTANCIER PAT2)))) 
CIF CFILTPI PAT DAT) CLESCAPE T))) 
(SETQ ALIST ALI ST2) 
CNCYINCI PAT3 (NEXTL DAT))) 
(SETO ALIST (CDR ALIST2)) 
NIL)))) 
CCEQ CCAR PAT) '/ 7) 


(SETQ ALIST (CØNS (LIST (CADR PAT) DAT) ALIST))) 
CCATOM DAT) NIL) 


CCFILTRI CNEXTL PAT) CNEXTL DAT)) CFILTRI PAT DAT)))) 
FILTR! 
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ÅPPENDICE 4 


M-PLASMA EN VLISP 


(SETA SN@SY NIL) 

(MCHAR /1 (LAMBDA () ‘/1)) 

CMCHAR /T (LAMBDA (33 PES) 
(SETQ RES (LIST *LIST)) 
CWHILE (NEN (SETQ X CPEAD)) ‘/1) (NC@NCI RES X)) 
RES) 


(DE ERROR -L- 
(PRINT -L-) 
CWHILE (NEQ (STATUS 5) ‘/ 3 (PRINT CEVAL CREAD)))) 
T) 


CDE M-PLASMA () 
(SETQ #0K T #TGT STAPLEUEL #MSG '(MSG: CENTER M-PLASMA)) #LZC NIL) 
(D@I TAGAIN) 
' ØK) 


(DE D@ITAGAIN (€) 

(WHILE #@K 
CIF $NØSY CEPROP "BREAK 'LO@P)) 
CSETQ #TGTI #TGT) 
CNEX TL #TGTI1) 
CIF CEQ CCAAP #TGTI) *CL@S:) 

CMACC (CADP (NEXTL #TGT1)) 
"(LAMBDA (-X-) (SET (CAR -X¥-) (CADP X=-))))) 

CSETR #LØC (CADR (NEXTL #TGT1))) 
C(MATCH-PACK CNEXTL #TGTI) #™SG) 
CEPROGN #TGTI]) 

)) 


(DE MATCH-PACK (-P- -D-) (COND 
CCNULL -P-) T) 
( (NULL -D-) CERRØR "MATCH ‘PACK (CAR -F-))) 
(CEQ CCAR -P-) (CAP -D-)) 
CIF (MATCH-PACK (CDCP -P-) (CDDR -D-)) CPRØGN 
CIF CATOM (CADR -P-)) (SET (CADP -P-) (CCAD? -D-)) 
CSETA -D- (CAD? -D-)) 
(MAPC (CDR (CACR -P-)) 
"CLAMBDA (-X-) (SET -X- (NEXTL -D-))))) 
T))) 
CT CMATCH-PACX -P- (CECR -D-))))) 
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CDF IS C-L-) 
(SETQ #LØC NIL) 
CPUT CCAR -L-) T 'M-PLASMA) 
(SCAN-RECFIVER (CADPR -L-) #LØC) 
(SET CCAR -L-) (PRE (CACR -L-))) 
(CAR -L-)) 


(DE SCAN-RECEIVER (L LOC) (COND 
CCNULL L)) 
CCES CCAR L) ‘/=/>) 
CRPLACB L (MCONS '/=/> 
('L@C: CSETE AUX CSCAN-MSG (CADR L)))1. 
(CDP L))) 
(SCAN-RECEIVE®S (CDEDP L) (NCONC AUX LØC))) 
CCATOM CCAR L)) CSCAN-RECEIVER (CDR L) LOC)) 
CT CSCAN-RECEI VER (NEXTL L) LOC) CSCAN-RECEIVER L L@C)) 
>) 


(DE SCAN-MSG (L 33 
(SETA RES (CØNS)) 
(WHILE L 

CIF CATOM (CADR L)) CNCONCI RES (CADR L)) 
(NCØNC PES (APPEND (CDR (CADR L))))) 


RES) 


CSETA L CCDDR L))) 
(CDR RES)) 


(DE PRE (X) (CAND 
CCATOM X) X) 
(CEN CCADR X) '/</=) C°SENE (PRE (CAR X)) (PRE (CADDR X)) 1) 
(T (CONS (PRE (CAR ¥)) (PRE (CDR X)) )))) 


(DM SEND (CALL) (RPLACB CALL 
C*SETQ '#SENDER '#TGT 
* #TGT CCOND ((LISTP (CACR CALL))CQUBTE ( CADR CALL) 1) 
(CEQ CCADR CALL) ‘SSELF) ‘#TGT) 
CT (CADR CALL) )) 
t #MSG C'EVAL-MSG CQUOTE CCADDR CALL)1171)) 


(DE EVAL-MSG C-L=-) CCOND 
CCNULL -L-) NIL) 
CCSETQ AUX (GET CCAR -L-) "PACKAGER)) 
(MCONS CCAR -L-) CAUX (CADR -L-)) CEVAL-MSG (CDDP -L-)))) 
(T CERROR ‘EVAL-MSG *PACKAGER (CAR -L-))))) 
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(DF D-PACK (L) 
(PUT (CAR L> (CONS LAMBDA (CEP L)) *PACKAGER)) 


(D-PACK MSG: C-X-) (EVAL -X-)) 


(D-PACK CONT: (-X-) 
CIF CATOM -KX-) (EVAL -X-) 
(MCONS "/=/> C°CLOS: (MK-CLØS) 1 (CDR -X-)))) 


(DE MK-CL@S ¢) 
CMAPCAR #L@C *CLAMBDA (-x-) C-X- (EVAL -X-) 1 ))) 


CIS STØPL EVEL 
(=> (MSG: X) 
(PRINT X) 
(SEND $EVAL (MSG: (PRE CREAD)) CONT: $TOP)))) 


CIS $TØP 
(=> (MSG: X) 
(PRINT 'ANSWER ‘IS x) 
(SEND STØPLEVEL (MSG: '(M-PLASMA TØF))))) 


CIS SEVAL 
(=> (MSG: E CONT: C) 
CIF CEQ (CAR E) *SEND) (EVAL E) 
CSEND C (MSG: (EVAL E)))))) 
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APPENDICE 5 


MODULE DE VISUALISATION DE ZONE DE CONTROLE EN VLISP T1600 


L'appel (VISPIL) imprime l'état de la pile de récursion grace au module 
LAP T1600 : 


CLAP CVISSIL CF) 
CLR K B) 
CECR GON SN) 
(LB AENIL) 
CHS CEN St) 
CETA A4) 
CLA 'CLAYELA (X) 
CIF (LT X CLØC (CAITR “CAERII) “CTERFPRED 
CTRINT Y 
(LET CCX CCAR (UAG ¥)))) (CAD 
CCAR CNIMGP XY) CLISTF ¥)) X) 
CCAND CATEM X) CGE (LAC XY) CLBC NIL))) X) 
CCLC SIF 
CSELF CSUR XIDI) 


(STA A1) 
CBN APELYF) 
€)) 


LAP T1600, l'assembleur VLISP, permet de mélanger librement des instructions- 
machine T1600 en LAP, à des segments en VLISP. 


L'adresse du fond de la pile est en P.valeur de l'atome standard CADR. 


Les fonctions standard LOC et VAG donnent accès illimité å la mémoire en 


adresses absolues. 


CLOC x) transforme en nombre VLISP l'adresse absolue de l'objet x : 
liste ou atome 


(VAG x) transforme le nombre VLISP x en adresse absolue. 
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APPENDICE 6 
ENTREES-SORTIES VLISP 


ET 
MACROS D'ENTREES-SORTIES MACIN ET MACOUT 


Le module READ utilise les fonctions auxiliaires 


CRATOM) : lit un atome 
CNATOM x) : teste si l'argument x est normal i.e. distinct 
de point ou parenthèse gauche ou droite 
RPAR une parenthèse droite 
CILPAR!I x) testent si x est june parenthèse gauche 
DOT un point 


CDE READ () (CLET CCX CRATOM))) CCOND 
CCNATOM X) X) 
CCLPAR X) CRCAR)) 
CT CERREUR))))) 


(DE RCAR ©) CLET CCX CRATOM))) CCOND 
CCNATOM X) CLOOKMACIN CCONS X CRCDR)))) 
CCRPAR X) NIL) 

CCLPAR X) CCONS CRCAR) CRCDR))) 
CT CERREUR))))) 


CDE RCDR () CLET CCX CRATOM))) CCOND 
CCNATOM X) CCONS X CRCDR))) 
CCLPAR X) CCONS CRCAR) CRCDR))) 
CCDOT X) CLET CCX CREAD))) 
CIF CRPAR CRATOM)) X CERREUR)))) 
CCRPAR X) NIL)))) 


CDE LOOKMACIN (CE) 
(LET CCX (GET CCAR E) 'MACIN))) 
CIF X CAPPLY X CCDR E)) E))) 


CDF DMI CL) 
(PUT CCAR L) CCONS LAMBDA (CDR L)) 'MACIN)D) 
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Le module PRINT utilisera la fonction auxiliaire 
CPRATOM Gy. was dn) 


qui place les NOMS des atomes a, ... a, dans le buffer de sortie 


CDE PRINT E CCOND 
CCCDR E) CP-ELM CNEXTL E)) 
CAPPLY 'PRINT E)) 
CT CP-ELM CCAR E)) 
CTERPRI) 
CCAR E)))) 


(DE P-ELM (CE) 
CIF CATOM E) CPRATOM E) 
CLET CCX (GET CCAR E) 'MACOUT))) 
CIF X CAPPLY X (CDR E)) 
CPRATOM '/C D 
(P-ELM-2 E))))) 


(DE P-ELM-2 (E) 
(P-ELM CNEXTL E)) 
CIF CNULL E) CPRATOM '/) ) 
CPRATOM '/ ) 
CIF CLISTP E) (P-ELM-2 E) 
CPRATOM '/. '/ E '/) )))) 


CDF DMO CL) 
(PUT CCAR L) CCONS LAMBDA (CDR L)) 'MACOUT)) 
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APPENDICE 7 


LA CONSTRUCTION po DE MACLISP 
UNE MACRO VLISP 


(MCHA? f CLAMEDA () (LET CCSN ALT ET) 
CEF CIS Y VIS NTL 
(CØNS VY (SELF (READ))))))) 


(MCHAP 1 (LAMBDA CD ‘J)) 
(MCHAP " CLAMBDA ©) C'DREUAL COUQTE CPEAL)]1)) 


(DE DSEVAL (E) (COND 
CCAT@M E) E) 
CC= (CAR E) ',) CEVAL (CCP E))) 
((= (CAAR F) '€) CAPPENET CFVAL (CLAP §£)) 
| (SELF (CDP £)))) 
CT CCENS (SELF (NEXTL E)) (SELF E))))) 


(MCHAP >» (LAMBDA (>) (CZNS "s CREAL)))) 


(MCHA? @ (LAMBDA () (CANS "@ (PFAD)))) 


CDM DZ (CALL) cPrLacs CALL 
"CCLANDCA > CIAPCAP (CALP CALL) "CA®) 
CIF ,CCAALD? CALL) crragy @CCLADD® CALL) ) 
@CCEIDP CALL) 
(SELF @(MAPCA? (CADF CALL) *CADDP) )) 
SCMAPCAR ( CADP CALL) "CALP)))) | | i 


La construction DO est macro-générée en terme de SELF. Cette macro écrasante 


utilise elle-même les macros caractères ("), (,) et (@) définis au §6.2.5.2. 
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APPENDICE 8 


LA MACRO LET-MULTIPLE 


Ct LET << CALA): “CReGACe CALL 
C(LAMSDA (LUAR LVUAL) 
(CONS (CANS LAMBDA (CONS LVAR CCEDR CALL))) 
| LVAL)) 
CXLET CCADR CALL) CREVERSE CCAADR CALL)))))) 


CDE. XLET CE: XX) 
CTF ANVULE BD CHILTEPLE -CX 672 
(CLAMBLDA CY 7) 
(CMULTITLE CHC2ZNC (REVERSE (CDR ¥)) Y) 
CCINS (CAR X) Z))) 
(SELF (COR L) (REVERSE (CACR L)))))) 


Cette version de la macro LET supporte les valeurs multiples et utilise 
elle-même la fonction MULTIPLE (cf. §6.2.12). 
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APPENDICE 9 


DETECTION EN VLISP D'APPELS NPR ET CPR 


(DE MK-EPR-NER (NØM) 
CC-FRÇGN CCDDR (GET NOM EXPP)) *xNPRx)) 


(DE C-PROGN CE TYPE) (COND 
CCNULL E) NIL) 
CCCDP E) (SELF (CDR E) TYFPE)) 
CT CIF COR CATOM (CAP E)) CEQ (CAR E) QUOTED) NIL 
(C- EVAL (CAR E) TYPE))))) 


(DE C- EVAL (E TYPE) (CND 
CCLISTP CCAP E))) 
CCSETO TEMP (GET (CAP E) *MK=SPEC)) (TEMP (CDP E) TYPE)) 
(CØR CEQ CCAR E) N@M) (EQ (CCAR E) 'SELF)) 
(RPLACA E TYPE) 
CC-PROGN (CDR E) "xEPPx)) 
CCSUBRP (CAR E)) (C-PRAGN (CDR E) ‘x*xEPRx)))) 


(PUT ‘IF °C-IF "MK-SPEC) 

(DE C-IF CE TYPE) 
CC-PROGN (LIST CCADDP E)) TYPE) 
(C-PROGN CCDDR E) TYPE)) 


(FUT "CØND 'C-CØND ‘MK-SPEC) 
(CDE C-COND CE TYPE) 
CIF (NULL E) NIL 
€C-PRIGN (CAR E) TYPE) 
(SELF (CDR E) TYPE))) 


L'appel CMK-EPR-NPR ‘une-fonction) 

substitue dans le corps de la-fonetton tous les appels NPR de 
Cla-fonetton ?-) 

par ©. C*NPR* ?-) 

et tous les appels EPR de 
Cla-fonetton ?-) 


par CXEPR* ?-) 
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